Extended Optional Parameters Length for BGP OPEN Message
draft-ietf-idr-ext-opt-param-13

[Ballot comment]
Thanks for this short and sweet document; I have very little to say.

Section 2

And we're sure that a two-byte length is going to be enough "for ever",
right?

Section 3

  MUST NOT be used other than as described above.  If encountered as an
  actual Optional Parameter Type code, it MUST be treated as an

Is "actual Option Parameter Type code" synonymous with "in any position
other than the first option parameter type"?  In some sense "actual
Option Parameter" seems slightly under-specified.

[Ballot comment]
[ Thank you for addressing my concern - clearing my DISCUSS]


Thank you for this document. It is clear, and solves a real problem.

Also, thanks to Al Morton for his OpsDir review - as always, it is much appreciated.

[Ballot comment]
I agree with Rob. Though not at all an expert on BGP, I think that if BGP nodes MUST NOT use the new encoding for smaller parameter sets, that is going to make it harder to test for the capability on the internet and reduce the incentives to support this specification. I would suggest that instead they SHOULD use the RFC4271 encoding, possibly discussing the reasons one might not.

[Ballot comment]
This was a quick read, thanks.

Comments:

  * Section 3 :

        A warning MAY be logged.
   
    This is ambiguous to me, if this is not considered as Error then why there will be a warning. And it is also not clear what will be the warning about.

[Ballot comment]
Thank you for this document. It is clear, and solves a real problem.

Also, thanks to Al Morton for his OpsDir review - as always, it is much appreciated.

[Ballot discuss]
This should be a trivial to clear DISCUSS.
This text terrifies me:
"It is not considered a fatal error to receive an OPEN message whose (non-extended) Optional Parameters Length value is not 255, and whose first Optional Parameter type code is 255 -- in this case the encoding of this specification MUST be used for decoding the message. A warning MAY be logged."
It smacks of trying to be too clever, and that the correct response (IMO) when trying to set up a session with something obviously broken is to abort and throw an error.

However, I'm sure that there was some discussion, and that the WG decided that this was a good idea; unfortunately I was unable to find anything discussion on this, so all I'm asking for is some reassurance that this was discussed and that this behavior was chosen as a good idea...

[Ballot comment]
Hi,

Thanks for this document, I found it relatively easy to read and understand even though I'm not particularly familiar with BGP.

There were a couple of areas of the document that I found slightly confusing, or inconsistent.  However, I do not feel strongly on these and will leave it to the authors/WG to decide how to handle these:

1. I found it slightly inconsistent that section 2 states:

  In the event that the length of Optional Parameters in the BGP OPEN
  message does not exceed 255, the encodings of the base BGP
  specification [RFC4271] MUST be used without alteration.

and at the same time, section 3 states:

  It is not considered an error to receive an OPEN message whose
  Extended Optional Parameters Length value is less than or equal to
  255.

To me, I think this means that it would be better as a SHOULD rather than a MUST, or perhaps change section 3 to indicate that it a non-conformant encoding, but one that should be handled anyway.

2.
  In parsing an OPEN message, if the one-octet "Optional Parameters
  Length" field is non-zero, a BGP speaker MUST use the value of the
  octet following the one-octet "Optional Parameters Length" field to
  determine both the encoding of the Optional Parameters length and the
  size of the "Parameter Length" field of individual Optional
  Parameters.  If the value of this field is 255, then the encoding
  described above is used for the Optional Parameters length.
  Otherwise the encoding defined in [RFC4271] is used.

I wasn't really sure what this paragraph was stating beyond what had already been stated previously in section 2, hence I'm wondering if it is required at all.  If it does remain then I found the reference to "Optional Parameters Length" is perhaps not as clear as it could be, and perhaps it would be better to refer to the "Non-Ext OP Len" field (as per the diagram), and perhaps to the "Non-Ext OP Type" field rather than the 'octet following the one-octet "Optional Parameters Length" field'.

Regards,
Rob

[Ballot comment]
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 3, paragraph 3, nit:
-    it is not a bonafide Optional Parameter Type in the usual sense, and
+    it is not a bona fide Optional Parameter Type in the usual sense, and
+                    +

[Ballot comment]
Thank you for the work put into this document. It sounds like it is really a useful extension to BGP-4.

Having written that, I must admit that I failed to understand the mechanism at first reading. It took me a while to cross reference this doc + IANA registry + RFC 4271 (but, for sure, I am not a BGP SW engineer!).

I suggest to mention, in section 2, that the Code Capability IANA registry for 255 was reserved per RFC 8810 (so not causing interoperation) as well as using the actual values 255 in figure 1 and finally add the figure 4.2 from RFC 4271 to be crystal clear for the reader.

Should the "new speaker" behavior be specified when an "old speaker" close the connection ? I.e., retry if possible without using this specification ?

I hope that this helps to improve the document,

Regards,

-éric

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-ext-opt-param-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the BGP OPEN Optional Parameter Types registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

the TEMPORARY registration for:

Value: 255
Name: Extended Length

will be made permanent and the reference changed to [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-04-09):

From: The IESG
To: IETF-Announce
CC: Susan Hares , aretana.ietf@gmail.com, draft-ietf-idr-ext-opt-param@ietf.org, idr-chairs@ietf.org, idr@ietf.org, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Extended Optional Parameters Length for BGP OPEN Message) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Extended Optional Parameters Length for
BGP OPEN Message'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-04-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Optional Parameters in the BGP OPEN message as defined in the
  base BGP specification are limited to 255 octets due to a one-octet
  length field.  BGP Capabilities are carried in this field and may
  foreseeably exceed 255 octets in the future, leading to concern about
  this limitation.

  This document updates RFC 4271 by extending, in a backward-compatible
  manner, the length of the Optional Parameters in the BGP OPEN.  The
  Parameter Length field of individual Optional Parameters is also
  extended.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time. 
(Date:  11/1/2019)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Type:  Proposed Standard
Why: Updates RFC4271 to allow longer optional parameter field.
Draft states:  Standard Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  The Optional Parameters in the BGP OPEN message as defined in the
  base BGP specification are limited to 255 octets due to a one-octet
  length field.  BGP Capabilities are carried in this field and may
  foreseeably exceed 255 octets in the future, leading to concern about
  this limitation.

  In this document we update RFC 4271 by extending, in a backward-
  compatible manner, the length of the Optional Parameters in the BGP
  OPEN.  The Parameter Length field of individual Optional Parameters
  is also extended.


Working Group Summary:

Work Group Support was solid for the need for
this feature in BGP.

Debate on this issues occurred over years
and concluded with a solid consensus on the solution.

Document Quality:

4 implementations exist in released code:  Juniper, Nokia, BIRD, and Open daylight.

For details of the implementation reports please see:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-ext-opt-param%20implementations

Personnel:
Document Shepherd: Susan Hares
AD: Alvaro Retana
Early RTG-DIR reviewers: 
1) -04.txt: Matthew Bocci - Has Issues
2) -07.txt: Joel  Halpern -  Ready with Nits

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

1) Review of technology desired (reading document and implementation report)
2) Shepherd review sent a suggestion to update to security section.

https://mailarchive.ietf.org/arch/msg/idr/I-NJotd8_5TFgJ_kSdcKI-mQim8/

    The shepherd does not believe that any well written implementation
    will have a security issue.  The issue is not the implementation or the
    technology, the issue will be whether the security reviewers understand
    that the carefully written specification is written to adhere to
    best practices for BGP implementations.  BGP implementations carefully
    handle buffer overruns in OPENs and the components of OPENS.

    The normally cavalier statement of "No additional security constraints"
    is the appropriate statement for this document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No. 

  Why I am sure:
    a) 4 implementations - 2 of which are open code bases.
    b) The review of technology over multiple years by key experts. 

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns. This addition to BGP is needed.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

John Scudder:
https://mailarchive.ietf.org/arch/msg/idr/WKxh-d5zyZfOvxpCmNz6pd-aXL8/

Enke Chen:
https://mailarchive.ietf.org/arch/msg/idr/s-H6xR9HiCvWNN_LW9kknAQcAK4/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Solid.  This WG draft was approved with solid agreement
and then it waited for implementations. 
4 implementations have been created.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal criteria reviews required.

(13) Have all references within this document been identified as either normative or informative?

yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downref RFCs referenced.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

It changes RFC4271.  This is noted on the front page.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

IANA has given an early code asignment of code 255  in BGP OPEN optional parameter types registry
for Extended Length type code.  See
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-11

The shepherd notes this is correct.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

no requirement.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No yang module.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time. 
(Date:  11/1/2019)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Type:  Proposed Standard
Why: Updates RFC4271 to allow longer optional parameter field.
Draft states:  Standard Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  The Optional Parameters in the BGP OPEN message as defined in the
  base BGP specification are limited to 255 octets due to a one-octet
  length field.  BGP Capabilities are carried in this field and may
  foreseeably exceed 255 octets in the future, leading to concern about
  this limitation.

  In this document we update RFC 4271 by extending, in a backward-
  compatible manner, the length of the Optional Parameters in the BGP
  OPEN.  The Parameter Length field of individual Optional Parameters
  is also extended.


Working Group Summary:

Work Group Support was solid for the need for
this feature in BGP.

Debate on this issues occurred over years
and concluded with a solid consensus on the solution.

Document Quality:

4 implementations exist in released code:  Juniper, Nokia, BIRD, and Open daylight.

For details of the implementation reports please see:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-ext-opt-param%20implementations

Personnel:
Document Shepherd: Susan Hares
AD: Alvaro Retana
Early RTG-DIR reviewers: 
1) -04.txt: Matthew Bocci - Has Issues
2) -07.txt: Joel  Halpern -  Ready with Nits

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

1) Review of technology desired (reading document and implementation report)
2) Shepherd review sent a suggestion to update to security section.

    The shepherd does not believe that any well written implementation
    will have a security issue.  The issue is not the implementation or the
    technology, the issue will be whether the security reviewers understand
    that the carefully written specification is written to adhere to
    best practices for BGP implementations.  BGP implementations carefully
    handle buffer overruns in OPENs and the components of OPENS.

    The normally cavalier statement of "No additional security constraints"
    is the appropriate statement in this case. 

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No. 

  Why I am sure:
    a) 4 implementations - 2 of which are open code bases.
    b) The review of technology over multiple years by key experts. 

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns. This addition to BGP is needed.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

John Scudder:
https://mailarchive.ietf.org/arch/msg/idr/WKxh-d5zyZfOvxpCmNz6pd-aXL8/

Enke Chen:
https://mailarchive.ietf.org/arch/msg/idr/s-H6xR9HiCvWNN_LW9kknAQcAK4/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Solid.  This WG draft was approved with solid agreement
and then it waited for implementations. 
4 implementations have been created.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal criteria reviews required.

(13) Have all references within this document been identified as either normative or informative?

yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downref RFCs referenced.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

It changes RFC4271.  This is noted on the front page.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

IANA has given an early code asignment of code 255  in BGP OPEN optional parameter types registry
for Extended Length type code.  See
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-11

The shepherd notes this is correct.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

no requirement.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No yang module.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time. 
(Date:  11/1/2019)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Type:  Proposed Standard
Why: Updates RFC4271 to allow longer optional parameter field.
Draft states:  Standard Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  The Optional Parameters in the BGP OPEN message as defined in the
  base BGP specification are limited to 255 octets due to a one-octet
  length field.  BGP Capabilities are carried in this field and may
  foreseeably exceed 255 octets in the future, leading to concern about
  this limitation.

  In this document we update RFC 4271 by extending, in a backward-
  compatible manner, the length of the Optional Parameters in the BGP
  OPEN.  The Parameter Length field of individual Optional Parameters
  is also extended.


Working Group Summary:

Work Group Support was solid for the need for
this feature in BGP.

Debate on this issues occurred over years
and concluded with a solid consensus on the solution.

Document Quality:

4 implementations exist in released code:  Juniper, Nokia, BIRD, and Open daylight.

For details of the implementation reports please see:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-ext-opt-param%20implementations

Personnel:
Document Shepherd: Susan Hares
AD: Alvaro Retana
Early RTG-DIR reviewers: 
1) -04.txt: Matthew Bocci - Has Issues
2) -07.txt: Joel  Halpern -  Ready with Nits

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

1) Review of technology desired (reading document and implementation report)
2) Shepherd review sent a suggestion to update to security section.

    The shepherd does not believe that any well written implementation
    will have a security issue.  The issue is not the implementation or the
    technology, the issue will be whether the security reviewers understand
    that the carefully written specification is written to adhere to
    best practices for BGP implementations.  BGP implementations carefully
    handle buffer overruns in OPENs and the components of OPENS.

    The normally cavalier statement of "No additional security constraints"
    is the appropriate statement in this case. 

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No. 

  Why I am sure:
    a) 4 implementations - 2 of which are open code bases.
    b) The review of technology over multiple years by key experts. 

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns. This addition to BGP is needed.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

John Scudder:
https://mailarchive.ietf.org/arch/msg/idr/WKxh-d5zyZfOvxpCmNz6pd-aXL8/

Enke Chen:
https://mailarchive.ietf.org/arch/msg/idr/s-H6xR9HiCvWNN_LW9kknAQcAK4/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Solid.  This WG draft was approved with solid agreement
and then it waited for implementations. 
4 implementations have been created.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal criteria reviews required.

(13) Have all references within this document been identified as either normative or informative?

yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downref RFCs referenced.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

It changes RFC4271.  This is noted on the front page.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

IANA has given an early code asignment of code 255  in BGP OPEN optional parameter types registry
for Extended Length type code.  See
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-11

The shepherd notes this is correct.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

no requirement.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No yang module.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time. 
(Date:  11/1/2019)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Type:  Proposed Standard
Why: Updates RFC4271 to allow longer optional parameter field.
Draft states:  Standard Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  The Optional Parameters in the BGP OPEN message as defined in the
  base BGP specification are limited to 255 octets due to a one-octet
  length field.  BGP Capabilities are carried in this field and may
  foreseeably exceed 255 octets in the future, leading to concern about
  this limitation.

  In this document we update RFC 4271 by extending, in a backward-
  compatible manner, the length of the Optional Parameters in the BGP
  OPEN.  The Parameter Length field of individual Optional Parameters
  is also extended.


Working Group Summary:

Work Group Support was solid for the need for
this feature in BGP.

Debate on this issues occurred over years
and concluded with a solid consensus on the solution.

Document Quality:

4 implementations exist in released code:  Juniper, Nokia, BIRD, and Open daylight.

For details of the implementation reports please see:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-ext-opt-param%20implementations

Personnel:
Document Shepherd: Susan Hares
AD: Alvaro Retana
Early RTG-DIR reviewers: 
1) -04.txt: Matthew Bocci - Has Issues
2) -07.txt: Joel  Halpern -  Ready with Nits

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

1) Review of technology desired (reading document and implementation report)
2) Shepherd review sent a suggestion to update to security section.

    The shepherd does not believe that any well written implementation
    will have a security issue.  The issue is not the implementation or the
    technology, the issue will be whether the security reviewers understand
    that the carefully written specification is written to adhere to
    best practices for BGP implementations.  BGP implementations carefully
    handle buffer overruns in OPENs and the components of OPENS.

    The normally cavalier statement of "No additional security constraints"
    is the appropriate statement in this case. 

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No. 

  Why I am sure:
    a) 4 implementations - 2 of which are open code bases.
    b) The review of technology over multiple years by key experts. 

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns. This addition to BGP is needed.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

John Scudder:
https://mailarchive.ietf.org/arch/msg/idr/WKxh-d5zyZfOvxpCmNz6pd-aXL8/

Enke Chen:
https://mailarchive.ietf.org/arch/msg/idr/s-H6xR9HiCvWNN_LW9kknAQcAK4/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Solid.  This WG draft was approved with solid agreement
and then it waited for implementations. 
4 implementations have been created.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal criteria reviews required.

(13) Have all references within this document been identified as either normative or informative?

yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downref RFCs referenced.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

It changes RFC4271.  This is noted on the front page.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

IANA has given an early code asignment of code 255  in BGP OPEN optional parameter types registry
for Extended Length type code.  See
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-11

The shepherd notes this is correct.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

no requirement.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No yang module.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time. 
(Date:  11/1/2019)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Type:  Proposed Standard
Why: Updates RFC4271 to allow longer optional parameter field.
Draft states:  Standard Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  The Optional Parameters in the BGP OPEN message as defined in the
  base BGP specification are limited to 255 octets due to a one-octet
  length field.  BGP Capabilities are carried in this field and may
  foreseeably exceed 255 octets in the future, leading to concern about
  this limitation.

  In this document we update RFC 4271 by extending, in a backward-
  compatible manner, the length of the Optional Parameters in the BGP
  OPEN.  The Parameter Length field of individual Optional Parameters
  is also extended.


Working Group Summary:

Work Group Support was solid for the need for
this feature in BGP.

Debate on this issues occurred over years
and concluded with a solid consensus on the solution.

Document Quality:

4 implementations exist in released code:  Juniper, Nokia, BIRD, and Open daylight.

For details of the implementation reports please see:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-ext-opt-param%20implementations

Personnel:
Document Shepherd: Susan Hares
AD: Alvaro Retana
Early RTG-DIR reviewers: 
1) -04.txt: Matthew Bocci - Has Issues
2) -07.txt: Joel  Halpern -  Ready with Nits

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

1) Review of technology desired (reading document and implementation report)
2) Shepherd review sent a suggestion to update to security section.

    The shepherd does not believe that any well written implementation
    will have a security issue.  The issue is not the implementation or the
    technology, the issue will be whether the security reviewers understand
    that the carefully written specification is written to adhere to
    best practices for BGP implementations.  BGP implementations carefully
    handle buffer overruns in OPENs and the components of OPENS.

    The normally cavalier statement of "No additional security constraints"
    is the appropriate statement in this case. 

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No. 

  Why I am sure:
    a) 4 implementations - 2 of which are open code bases.
    b) The review of technology over multiple years by key experts. 

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns. This addition to BGP is needed.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

John Scudder:
https://mailarchive.ietf.org/arch/msg/idr/WKxh-d5zyZfOvxpCmNz6pd-aXL8/

Enke Chen:
https://mailarchive.ietf.org/arch/msg/idr/s-H6xR9HiCvWNN_LW9kknAQcAK4/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Solid.  This WG draft was approved with solid agreement
and then it waited for implementations. 
4 implementations have been created.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal criteria reviews required.

(13) Have all references within this document been identified as either normative or informative?

yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downref RFCs referenced.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

It changes RFC4271.  This is noted on the front page.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

IANA has given an early code asignment of code 255  in BGP OPEN optional parameter types registry
for Extended Length type code.  See
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-11

The shepherd notes this is correct.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

no requirement.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No yang module.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time. 
(Date:  11/1/2019)


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Type:  Proposed Standard
Why: Updates RFC4271 to allow longer optional parameter field.
Draft states:  Standard Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:



Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?