Hi Peter, Thanks for thoroughly reviewing this document again and finding the nits. I incorporated all your comments other than adding "positive" as while it is more precise, it reads better without it and we don't want to imply that a TLV length could ever be negative. See attached diff. Thanks, Acee
On 6/13/18, 3:04 AM, "Peter Yee" <[email protected]> wrote: Reviewer: Peter Yee Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-idr-bgp-prefix-sid-21 Reviewer: Peter Yee Review Date: 2018-06-12 IETF LC End Date: 2018-06-12 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication, although there are a few nits that should be corrected prior to publication. I am not a routing expert, so I cannot vouch for the correctness of this specification, but it otherwise appears consistent and reflect s the many iterations it has undergone. Major issues: None. Minor issues: None Nits/editorial comments: General: Expand uncommon acronyms on first use. (See: https://www.rfc-editor.org/materials/abbrev.expansion.txt.). Acronyms need expansion include: AS, ECMP, and EBGP. Specific: Page 3, 7th paragraph, last sentence: actually, this isn’t a complete sentence. I’m not sure what you wanted to do with the fragment. Page 5, 2nd full paragraph, last sentence: change “prefix-SID” to “BGP Prefix-SID” to make usage in the remainder of the document. Page 7, Section 3.2, 2nd bullet item: insert “positive” before “multiple”. Page 9, last paragraph, 1st sentence: delete “to”. Page 12, 1st paragraph after the (unlabeled) Value/Type/Reference table, last sentence: insert “ Prefix” before “-SID”. Page 12, 2nd paragraph after the (unlabeled) Value/Type/Reference table, last sentence: insert “ Prefix” before “-SID”.
< <https://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-prefix-sid-21.txt> draft-ietf-idr-bgp-prefix-sid-21.txt <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-21.txt> draft-ietf-idr-bgp-prefix-sid-22.txt <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-22.txt> > <https://tools.ietf.org/rfcdiff?url1=draft-ietf-idr-bgp-prefix-sid-22.txt> IDR S. Previdi, Ed. IDR S. Previdi, Ed. Internet-Draft C. Filsfils Internet-Draft C. Filsfils Intended status: Standards Track A. Lindem, Ed. Intended status: Standards Track A. Lindem, Ed. Expires: November 30, 2018 Cisco Systems Expires: December 15, 2018 Cisco Systems A. Sreekantiah A. Sreekantiah H. Gredler H. Gredler RtBrick Inc. RtBrick Inc. May 29, 2018 June 13, 2018 Segment Routing Prefix SID extensions for BGP Segment Routing Prefix SID extensions for BGP draft-ietf-idr-bgp-prefix-sid-21 draft-ietf-idr-bgp-prefix-sid-22 Abstract Abstract The Segment Routing (SR) architecture allows a node to steer a packet The Segment Routing (SR) architecture allows a node to steer a packet flow through any topological path and service chain by leveraging flow through any topological path and service chain by leveraging source routing. The ingress node prepends an SR header to a packet source routing. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SID). Each SID represents a containing a set of segment identifiers (SID). Each SID represents a topological or a service-based instruction. Per-flow state is topological or a service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An SR domain maintained only on the ingress node of the SR domain. An SR domain is defined as a single administrative domain for global SID is defined as a single administrative domain for global SID skipping to change at/page 2, line 10¶/ <#part-2> skipping to change at/page 2, line 10¶/ <#part-2> Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress." This Internet-Draft will expire on November 30, 2018. This Internet-Draft will expire on December 15, 2018. Copyright Notice Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents publication of this document. Please review these documents skipping to change at/page 3, line 15¶/ <#part-3> skipping to change at/page 3, line 15¶/ <#part-3> 1. Introduction 1. Introduction The Segment Routing (SR) architecture leverages the source routing The Segment Routing (SR) architecture leverages the source routing paradigm. A group of inter-connected nodes that use SR forms an SR paradigm. A group of inter-connected nodes that use SR forms an SR domain. A segment represents either a topological instruction such domain. A segment represents either a topological instruction such as "go to prefix P following shortest path" or a service instruction. as "go to prefix P following shortest path" or a service instruction. Other types of segments may be defined in the future. Other types of segments may be defined in the future. A segment is identified through a Segment Identifier (SID). An SR A segment is identified through a Segment Identifier (SID). An SR domain is defined as a single administrative domain for global SID domain is defined as a single administrative domain for global SID assignment. It may be comprised of a single AS or multiple ASes assignment. It may be comprised of a single Autonomous System (AS) under consolidated global SID administration. Typically, the ingress or multiple ASes under consolidated global SID administration. node of the SR domain prepends an SR header containing segments Typically, the ingress node of the SR domain prepends an SR header identifiers (SIDs) to an incoming packet. containing segments identifiers (SIDs) to an incoming packet. As described in [I-D.ietf-spring-segment-routing], when SR is applied As described in [I-D.ietf-spring-segment-routing], when SR is applied to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]), the to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]), the SID consists of a label. SID consists of a label. [I-D.ietf-spring-segment-routing] also describes how segment routing [I-D.ietf-spring-segment-routing] also describes how segment routing can be applied to an IPv6 dataplane (SRv6) using an IPv6 routing can be applied to an IPv6 dataplane (SRv6) using an IPv6 routing header containing a stack of SR SIDs encoded as IPv6 addresses header containing a stack of SR SIDs encoded as IPv6 addresses [I-D.ietf-6man-segment-routing-header]. The applicability and [I-D.ietf-6man-segment-routing-header]. The applicability and support for Segment Routing over IPv6 is beyond the scope of this support for Segment Routing over IPv6 is beyond the scope of this document. document. A BGP-Prefix Segment (and its BGP Prefix-SID) is a BGP segment A BGP-Prefix Segment (and its BGP Prefix-SID) is a BGP segment attached to a BGP prefix. A BGP Prefix-SID is always a global SID attached to a BGP prefix. A BGP Prefix-SID is always a global SID ([I-D.ietf-spring-segment-routing]) within the SR/BGP domain (i.e., ([I-D.ietf-spring-segment-routing]) within the SR/BGP domain (i.e., the set of Autonomous Systems under a common administration and the set of Autonomous Systems under a common administration and control and where SR is used) and identifies an instruction to control and where SR is used) and identifies an instruction to forward the packet over the ECMP-aware best-path computed by BGP to forward the packet over the Equal-Cost Multi-Path (ECMP) best-path the related prefix. The BGP Prefix-SID is the identifier of the BGP computed by BGP to the related prefix. The BGP Prefix-SID is the prefix segment. In this document, we always refer to the BGP segment identifier of the BGP prefix segment. In this document, we always by the BGP Prefix-SID. refer to the BGP segment by the BGP Prefix-SID. This document describes the BGP extension to signal the BGP Prefix- This document describes the BGP extension to signal the BGP Prefix- SID. Specifically, this document defines a BGP attribute known as SID. Specifically, this document defines a BGP attribute known as the BGP Prefix-SID attribute and specifies the rules to originate, the BGP Prefix-SID attribute and specifies the rules to originate, receive, and handle error conditions for the attribute. receive, and handle error conditions for the attribute. The BGP Prefix-SID attribute defined in this document can be attached The BGP Prefix-SID attribute defined in this document can be attached to prefixes from Multiprotocol BGP labeled IPv4/IPv6 Unicast to prefixes from Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC4760], [RFC8277]). Address Family Identifier (AFI)/ Subsequent ([RFC4760], [RFC8277]). Usage of the BGP Prefix-SID attribute for Address Family Identifier (SAFI) combinations. other Address Family Identifier (AFI)/ Subsequent Address Family Identifier (SAFI) combinations is not defined herein but may be Usage of the BGP Prefix-SID attribute for other AFI/SAFI combinations specified in future specifications. is not defined herein but may be specified in future specifications. [I-D.ietf-spring-segment-routing-msdc] describes example use cases [I-D.ietf-spring-segment-routing-msdc] describes example use cases where the BGP Prefix-SID is used for the above AFI/SAFI combinations. where the BGP Prefix-SID is used for the above AFI/SAFI combinations. It should be noted that: It should be noted that: o A BGP Prefix-SID MAY be global between domains when the o A BGP Prefix-SID MAY be global between domains when the interconnected domains agree on the SID allocation scheme. interconnected domains agree on the SID allocation scheme. Alternatively, when interconnecting domains, the ASBRs of each Alternatively, when interconnecting domains, the ASBRs of each domain will have to handle the advertisement of unique SIDs. The domain will have to handle the advertisement of unique SIDs. The skipping to change at/page 5, line 19¶/ <#part-4> skipping to change at/page 5, line 19¶/ <#part-4> if traffic-engineering within the SR domain is required, each node if traffic-engineering within the SR domain is required, each node may be required to advertise its local SRGB in addition to the may be required to advertise its local SRGB in addition to the topological information. topological information. This document assumes that BGP-LS is the preferred method for This document assumes that BGP-LS is the preferred method for collecting both peer segments (Peer SIDs) and SRGB information collecting both peer segments (Peer SIDs) and SRGB information through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and [I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an [I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an optional alternative for the advertisement of the local SRGB optional alternative for the advertisement of the local SRGB without the topology nor the peer SIDs, hence without without the topology nor the peer SIDs, hence without applicability for TE, the Originator SRGB TLV of the prefix-SID applicability for TE, the Originator SRGB TLV of the BGP Prefix- attribute is specified in Section 3.2 of this document. SID attribute is specified in Section 3.2 of this document. As defined in [I-D.ietf-spring-segment-routing], the label index As defined in [I-D.ietf-spring-segment-routing], the label index L_I is an offset into the SRGB. Each BGP speaker derives its L_I is an offset into the SRGB. Each BGP speaker derives its local MPLS label, L, by adding L_I to the start value of its own local MPLS label, L, by adding L_I to the start value of its own SRGB, and programs L in its MPLS dataplane as its incoming/local SRGB, and programs L in its MPLS dataplane as its incoming/local label for the prefix. It should be noted that while SRGBs and label for the prefix. It should be noted that while SRGBs and SIDs are advertised using 32-bit values, the derived label is SIDs are advertised using 32-bit values, the derived label is advertised in the 20 right-most bits. See Section 4.1 for more advertised in the 20 right-most bits. See Section 4.1 for more details. details. skipping to change at/page 8, line 34¶/ <#part-5> skipping to change at/page 8, line 34¶/ <#part-5> The originator SRGB may only appear in a BGP Prefix-SID attribute The originator SRGB may only appear in a BGP Prefix-SID attribute attached to Labeled IPv4/IPv6 unicast prefixes ([RFC8277]). It MUST attached to Labeled IPv4/IPv6 unicast prefixes ([RFC8277]). It MUST be ignored when received for other BGP AFI/SAFI combinations. Since be ignored when received for other BGP AFI/SAFI combinations. Since the Label-Index TLV is required for IPv4/IPv6 prefix applicability, the Label-Index TLV is required for IPv4/IPv6 prefix applicability, the originator SRGB will be ignored if it is not specified consistent the originator SRGB will be ignored if it is not specified consistent with Section 6. with Section 6. 4. Receiving BGP Prefix-SID Attribute 4. Receiving BGP Prefix-SID Attribute A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP A BGP speaker receiving a BGP Prefix-SID attribute from an External neighbor residing outside the boundaries of the SR domain MUST BGP (EBGP) neighbor residing outside the boundaries of the SR domain discard the attribute unless it is configured to accept the attribute MUST discard the attribute unless it is configured to accept the from the EBGP neighbor. A BGP speaker SHOULD log an error for attribute from the EBGP neighbor. A BGP speaker SHOULD log an error further analysis when discarding an attribute. for further analysis when discarding an attribute. 4.1. MPLS Dataplane: Labeled Unicast 4.1. MPLS Dataplane: Labeled Unicast A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6 A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6 Unicast ([RFC8277]) AFI/SAFI is required. Unicast ([RFC8277]) AFI/SAFI is required. The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY contain the Originator SRGB TLV. A BGP Prefix-SID attribute received contain the Originator SRGB TLV. A BGP Prefix-SID attribute received without a Label-Index TLV MUST be considered as "invalid" by the without a Label-Index TLV MUST be considered as "invalid" by the receiving speaker. receiving speaker. skipping to change at/page 9, line 47¶/ <#part-6> skipping to change at/page 9, line 47¶/ <#part-6> When a BGP speaker receives a path from a neighbor with an "invalid" When a BGP speaker receives a path from a neighbor with an "invalid" or "conflicting" BGP Prefix-SID attribute or when a BGP speaker or "conflicting" BGP Prefix-SID attribute or when a BGP speaker receives a path from a neighbor with a BGP Prefix-SID attribute but receives a path from a neighbor with a BGP Prefix-SID attribute but is unable to process it (e.g., local policy disables the is unable to process it (e.g., local policy disables the functionality), it MUST ignore the BGP Prefix-SID attribute. For the functionality), it MUST ignore the BGP Prefix-SID attribute. For the purposes of label allocation, a BGP speaker MUST assign a local (also purposes of label allocation, a BGP speaker MUST assign a local (also called dynamic) label (non-SRGB) for such a prefix as per classic called dynamic) label (non-SRGB) for such a prefix as per classic Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker MUST follow to the error handling rules specified in Section 6. A MUST follow the error handling rules specified in Section 6. A BGP BGP speaker SHOULD log an error for further analysis. In the case of speaker SHOULD log an error for further analysis. In the case of a a "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT treat it as error and SHOULD propagate the attribute unchanged. A treat it as error and SHOULD propagate the attribute unchanged. A BGP Speaker SHOULD log a warning for further analysis, i.e., in the BGP Speaker SHOULD log a warning for further analysis, i.e., in the case the conflict is not due to a label index transition. case the conflict is not due to a label index transition. When a BGP Prefix-SID attribute changes and transitions from When a BGP Prefix-SID attribute changes and transitions from "conflicting" to "acceptable", the BGP Prefix-SID attributes for "conflicting" to "acceptable", the BGP Prefix-SID attributes for other prefixes may also transition to "acceptable" as well. other prefixes may also transition to "acceptable" as well. Implementations SHOULD assure all impacted prefixes revert to using Implementations SHOULD assure all impacted prefixes revert to using the label indices corresponding to these newly "acceptable" BGP the label indices corresponding to these newly "acceptable" BGP Prefix-SID attributes. Prefix-SID attributes. skipping to change at/page 12, line 26¶/ <#part-7> skipping to change at/page 12, line 26¶/ <#part-7> 1 Label-Index this document 1 Label-Index this document 2 Deprecated this document 2 Deprecated this document 3 Originator SRGB this document 3 Originator SRGB this document 4-254 Unassigned 4-254 Unassigned 255 Reserved this document 255 Reserved this document This document also requests creation of the "BGP Prefix-SID Label- This document also requests creation of the "BGP Prefix-SID Label- Index TLV Flags" registry under the "Border Gateway Protocol (BGP) Index TLV Flags" registry under the "Border Gateway Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid. Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid. Initially, this 16 bit flags registry will be empty. Flag bits will Initially, this 16 bit flags registry will be empty. Flag bits will be allocated First Come First Served (FCFS) consistent with the BGP- be allocated First Come First Served (FCFS) consistent with the BGP SID TLV Types registry. Prefix-SID TLV Types registry. Finally, this document requests creation of the "BGP Prefix-SID Finally, this document requests creation of the "BGP Prefix-SID Originator SRGB TLV Flags" registry under the "Border Gateway Originator SRGB TLV Flags" registry under the "Border Gateway Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp- Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp- prefix-sid. Initially, this 16 bit flags registry will be empty. prefix-sid. Initially, this 16 bit flags registry will be empty. Flag bits will be allocated First Come First Served (FCFS) consistent Flag bits will be allocated First Come First Served (FCFS) consistent with the BGP-SID TLV Types registry. with the BGP Prefix-SID TLV Types registry. 8. Manageability Considerations 8. Manageability Considerations This document defines a BGP attribute to address use cases such as This document defines a BGP attribute to address use cases such as the one described in [I-D.ietf-spring-segment-routing-msdc]. It is the one described in [I-D.ietf-spring-segment-routing-msdc]. It is assumed that advertisement of the BGP Prefix-SID attribute is assumed that advertisement of the BGP Prefix-SID attribute is controlled by the operator in order to: controlled by the operator in order to: o Prevent undesired origination/advertisement of the BGP Prefix-SID o Prevent undesired origination/advertisement of the BGP Prefix-SID attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be skipping to change at/page 14, line 41¶/ <#part-8> skipping to change at/page 14, line 41¶/ <#part-8> [I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. in progress), January 2018. [I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-13 data plane", draft-ietf-spring-segment-routing-mpls-14 (work in progress), April 2018. (work in progress), June 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc- editor.org/info/rfc2119>. editor.org/info/rfc2119>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc- DOI 10.17487/RFC4271, January 2006, <https://www.rfc- editor.org/info/rfc4271>. editor.org/info/rfc4271>. skipping to change at/page 16, line 12¶/ <#part-9> skipping to change at/page 16, line 12¶/ <#part-9> Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 (work in progress), May 2018. (work in progress), May 2018. [I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-idr-bgpls-segment-routing-epe] Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Dong, "BGP-LS extensions for Segment Routing BGP Egress Dong, "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", draft-ietf-idr-bgpls-segment-routing- Peer Engineering", draft-ietf-idr-bgpls-segment-routing- epe-15 (work in progress), March 2018. epe-15 (work in progress), March 2018. [I-D.ietf-spring-segment-routing-msdc] [I-D.ietf-spring-segment-routing-msdc] Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P. Filsfils, C., Previdi, S., Dawra, G., Aries, E., and P. Lapukhov, "BGP-Prefix Segment in large-scale data Lapukhov, "BGP-Prefix Segment in large-scale data centers", draft-ietf-spring-segment-routing-msdc-08 (work centers", draft-ietf-spring-segment-routing-msdc-09 (work in progress), December 2017. in progress), May 2018. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>. [RFC5004] Chen, E. and S. Sangli, "Avoid BGP Best Path Transitions [RFC5004] Chen, E. and S. Sangli, "Avoid BGP Best Path Transitions from One External to Another", RFC 5004, from One External to Another", RFC 5004, DOI 10.17487/RFC5004, September 2007, <https://www.rfc- DOI 10.17487/RFC5004, September 2007, <https://www.rfc- editor.org/info/rfc5004>. editor.org/info/rfc5004>. End of changes. 15 change blocks. /35 lines changed or deleted/ // /34 lines changed or added/ This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ <http://www.tools.ietf.org/tools/rfcdiff/>
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
