Subject: [Idr] Review of draft-abraitis-bgp-version-capability-07

From: Alvaro Retana <[email-masked]>
Date: Wed, 19 Aug 2020 12:41:03 -0400

Dear Donatas:

Thank you for your work on this document!

I am reviewing your document prompted by the IESG Conflict Review
(rfc5742) requested by the ISE; I am the Shepherding AD.  I cc'd the
idr WG in case there are any comments on the document or my review.

In general, the document is mostly clear, and the functionality may be
of interest to some.  From that point of view, I think there are no
conflicts that prevent publication.  I have several comments below
(in-line).

However, I have a couple of points that would prevent me from
declaring the document as conflict-free.  I am cc'ing the ISE for
awareness of my current thinking.

(1) You do a very good job to highlight potential threats in the Security
    Considerations section.  But you also Normatively recommend (SHOULD) the
    use of encryption in the BGP Session.  While sensible, there are no
    Standards Track documents that currently do the same.  This
    recommendation, even if the draft points out that it "is not an IETF
    Standards Track document", can create confusion and potentially disrupt
    other IETF work.

    The threats that you identify are not exclusive to this extension, so the
    solution/mitigation shouldn't be either.  This issue should be easy to
    address -- I suggested alternative text below.

(2) As currently specified ("SHOULD be no greater than 64" and "it is
    RECOMMENDED to exclude the Version Capability"), the Capabilities Length
    Overflow (§3.1) handling represents a significant threat to a BGP
    session.  The recommendations are not enough to prevent the potential
    exclusion of other more critical Capabilities.  The use of
    draft-ietf-idr-ext-opt-param could reduce the risk, but may result in the
    same problem.

    Because the current specification may significantly affect any BGP
    session where one of the peers supports the Version Capability, I believe
    that this document would require IETF review.

    This issue can be addressed by requiring the exclusion of the Version
    Capability (using MUST), *and* talking about the risk in the Security
    Considerations section.  See more comments about this in-line in §3.1.

Note that this message is not the IESG's Conflict Review, just my
review of the document.  I have scheduled the balloting of the
Conflict Review for Sep/10, so we should have plenty of time to talk
about the two issues above.

Thanks!

Alvaro.

[Line numbers from idnits.]

...
10	Abstract
...
15	   This BGP capability is an optional advertisement.  Implementations
16	   are not required to advertise the version nor to process received
17	   advertisements.

[nit] All BGP Capabilities are optional.  No need to include this
paragraph.  The same text is repeated in the Introduction...and
similar text elsewhere.

...
66	1.  Introduction
...
79	   Information about the version of the routing daemon could also be
80	   exchanged in protocols such as LLDP and CDP.  However, in
81	   containerized environments, it is very hard and not recommended to
82	   exchange this information between background processes.  Therefore,
83	   and to help minimize operational costs, it is helpful to exchange the
84	   routing daemon information between BGP peers directly.

[nit] For completeness, it would be nice to have a reference to LLDP/CDP.

...
94	3.  Version Capability

96	   Although this document is not an IETF Standards Track document, it
97	   makes use of the terminology from BCP 14 in order to clearly state
98	   the implementation behaviors.

100	   Capabilities advertisements with BGP are defined in [RFC5492].  They
101	   utilize the BGP Capabilities Optional Parameter that contains one or
102	   more triples <Capability Code, Capability Length, Capability Value>.
103	   This document defines a new BGP capability, the Version Capability,
104	   with Capability Code TBD and Capability Length and Capability Value
105	   as described below.

107	   The inclusion of the Version Capability is OPTIONAL.  If an
108	   implementation supports the inclusion of the capability, the
109	   implementation MUST include a configuration switch to enable or
110	   disable its use, and that switch MUST be off by default.

112	   The Version Capability is intended principally more to non-production
113	   environments where more visibility is needed for troubleshooting
114	   purposes.  It is NOT RECOMMENDED for use outside single Autonomous
115	   System domain or Autonomous System Confederations, except you have a
116	   topology with a number of routers each with a separate Autonomous
117	   Number.

[nit] s/except you have/except if you have

[minor] A collection of several autonomous systems is often
characterized as being "under a common administration".  That
description covers not only "routers each with a separate Autonomous
Number", but also other combinations where multiple ASNs may be
present and where exchanging this information might be useful.

Suggestion>
   The Version Capability is intended for environments where more visibility
   is needed for troubleshooting purposes.  It is NOT RECOMMENDED for use
   outside a single Autonomous System, or a set of Autonomous Systems under
   a common administration.

119	   An implementation that does not recognize or support the Version
120	   Capability but which receives one MUST respond as described in
121	   [RFC5492] by ignoring the option.  An implementation that wishes to
122	   complain that its neighbor does not support the Version Capability
123	   MAY use the 'Unsupported Capability' Error Subcode of a Notification
124	   message as described in [RFC5492].

[major] The Normative behavior is already specified in rfc5492, please
don't re-specify the behavior here.  Note that rfc5492 specifies a
different behavior, specifically about sending a Notification:

   If a BGP speaker receives from its peer a capability that it does not
   itself support or recognize, it MUST ignore that capability.  In
   particular, the Unsupported Capability NOTIFICATION message MUST NOT
   be generated and the BGP session MUST NOT be terminated in response
   to reception of a capability that is not supported by the local
   speaker.

Suggestion>
   An implementation that does not recognize or support the Version
   Capability but receives one must ignore it, as described in [RFC5492].

...
132	   Capability Length

[minor] For completeness, please add the following from rfc5492:

         Capability Length is a one-octet unsigned binary integer that
         contains the length of the Capability Value field in octets.

134	      The Capability Length for the Version Capability MUST be greater
135	      than zero.  A value of zero SHALL be treated as an encoding error
136	      and the entire triple MUST be ignored.

[major] s/the entire triple MUST be ignored/the Capability MUST be ignored

138	      The Capability Length SHOULD be no greater than 64.  This is the
139	      limit to allow other capabilities as much space as they require.

[minor] Please add a forward reference to §3.1.  See more comments there.

141	   Capability Value
142	      The Capability Value field is encoded in UTF-8 [RFC3629].  It is
143	      unstructured data and can be formatted in any way that the
144	      implementor decides.

146	                   +--------------------------------+
147	                   |    Version Length (1 octet)    |
148	                   +--------------------------------+
149	                   |      Version (variable)        |
150	                   +--------------------------------+

152	                                 Figure 1

[minor] Just to make sure, this Figure represents the contents of the
Capability Value, right?  If so, it seems to me that the Version
Length is not needed because the Capability Length already
exists...and it takes up 1 octet from the Version.

154	   Version Length:

156	      The number of characters in the Version

[minor] If I remember correctly, UTF-8 uses variable-length character
encoding.  Is the variable-length part of the encoding?  A reference
to rfc3639 would be useful here.

[?] BTW, is there an advantage to signal the number of characters, vs
simply the number of octets?

158	   Version:

160	      The Version encoded via UTF-8

UTF-8 requires some extra considerations...borrowing from rfc8203:

Suggestion>
   The Version field MUST be encoded using UTF-8.  A receiving BGP speaker
   MUST NOT interpret invalid UTF-8 sequences. This field is not NUL
   terminated.

162	3.1.  Capabilities Length Overflow

164	   As defined in [RFC5492] the total length of capabilities that can be
165	   carried by the BGP Capabilities Optional Parameter is 255 bytes.  If
166	   an implementation is constructing a BGP Capabilities Optional
167	   Parameter and its length exceeds 255 bytes, it is RECOMMENDED to
168	   exclude the Version Capability.  An implementation may optimally
169	   achieve this by making the Version Capability the last capability
170	   triple to add to the Parameter, and only adding it if there is
171	   sufficient space to do so.

[?] Was the use of draft-ietf-idr-ext-opt-param considered?

[major] Some of the other Capabilities are far more critical to the
operation of a BGP session than this one: multiprotocol extensions,
extended messages, add-path...to mention a few.  As specified ("SHOULD
be no greater than 64" and "it is RECOMMENDED to exclude the Version
Capability"), the result could easily be the inability of the session
to properly function if other Capabilities are not included.

Why is the behavior recommended and not required?  I can imagine how a
Version may need a long string...but excluding the Version Capability
should be REQUIRED.

As mentioned at the top, text in the Security Considerations section
should also highlight this risk.

Suggestion (for the Security Considerations)>
   A rogue node can prevent the proper operation of a BGP session, or the
   advertisement of other Capabilities, by not excluding the Version
   Capability as required in Section 3.1.  This risk is equivalent to a rogue
   node simply not advertising a specific Capability and is not new to BGP.

[major] The length to be considered is not 255 octets of Capabilities,
but of Optional Parameters -- take a look at rfc4271/§4.2.

173	4.  Operation
...
186	   Enabling (i.e., turning on) this capability requires bouncing all
187	   existing BGP sessions and the feature MUST be explicitly configured
188	   before an implementation advertizes the Version Capability.

[minor] There is already a specification in §3 about explicit
configuration -- no need to specify the behavior twice.

Suggestion>
   Enabling (i.e., turning on) this capability may require a restart of any
   existing BGP sessions and its explicit configuration (Section 3).

[] Note that some vendors support the ability to change the software
version without restarting the BGP sessions...which means that the
Capability may have stale information.

190	4.1.  Example Usage

192	   Below is an example of implementation in [FRRouting] how it looks
193	   like with version advertised by a BGP sender:

[] Suggestion>
   Below is an example from the [FRRouting] implementation showing both the
   received and advertised Version Capability:

195	     :~# vtysh -c 'show ip bgp summary failed'
196	     ...
197	     Neighbor EstdCnt DropCnt ResetTime Reason
198	     ens192         3       3  00:00:35 Waiting for peer OPEN (n/a)
199	     ens224         3       3  00:01:12 Waiting for NHT (FRRouting 7.2)
200	     eth0           3       3  00:00:14 Neighbor deleted (FRRouting 7.3)
201	     ...

203	                                 Figure 2

[] I'm not sure what this figure is showing.

...
214	5.  IANA Considerations

216	   IANA maintains the "Border Gateway Protocol (BGP) Parameters"
217	   registry with a subregistry called "Capabilities Codes".  IANA is
218	   requested to assign a capability number from the First Come First
219	   Served range for the Version Capability in this document as follows:

[major] The Capability Codes registry is a standalone registry.

...
229	6.  Security Considerations

231	   The Version Capability should be treated as sensitive information: it
232	   could be easier for an attacker to exploit the system if they know
233	   the specific version of a BGP speaker.  This information could be
234	   gathered by inspecting BGP OPEN messages that carry the Version
235	   Capability defined in this document.  Using encryption to protect the
236	   information exchanged in BGP sessions SHOULD, therefore, be carefully
237	   considered when this feature is enabled.  Suitable encryption can be
238	   achieved by protecting the BGP session using TLS [RFC5246].

[major] There is no Standards Track document that talks about
encrypting a BGP session, much less recommending it (SHOULD).  This is
not an IETF consensus document, so providing this type of guidance is
out of place, and may cause unnecessary confusion that could disrupt
other work.

240	   Furthermore, knowledge of which versions of code is running on a
241	   given router and from which vendor it comes may facilitate a number
242	   of social-engineering attacks.  This further adds to the desire to
243	   protect this information through encryption.

245	   Modifying the information advertised by a router might lead to
246	   attacks including bogus software upgrades and also might mask the
247	   causes of faults in the network.  This can be mitigated by protecting
248	   the BGP session using TLS.

[major] Confidentiality and integrity are issues that apply to BGP in
general, and are not exclusive to this extension.

Suggestion (to replace the first 3 paragraphs -- borrowing heavily
from rfc8203)>

   The Version Capability should be treated as sensitive information: it
   could be easier for an attacker to exploit the system if they know the
   specific software version and manufacturer of a BGP speaker.  This
   information could be gathered by inspecting BGP OPEN messages that carry
   the Version Capability defined in this document.  Furthermore, this
   knowledge may facilitate a number of social-engineering attacks.

   Modifying the information advertised by a router might lead to attacks
   including bogus software upgrades and also might mask the causes of
   faults in the network.

   Users of this mechanism should be aware that unless a transport that
   provides integrity is used for the BGP session in question, the Version
   Capability can be forged.  Unless a transport that provides
   confidentiality is used, the Version Capability could be snooped by an
   attacker.  These issues are common to any BGP message but may be of
   greater interest in the context of this extension as explained above.
   Refer to the related considerations in [RFC4271] and [RFC4272].

   Users of this mechanism should consider applying data minimization
   practices as outlined in Section 6.1 of [RFC6973], as appropriate within
   the deployment context.

250	   Many BGP implementations leave TCP port 179 open in order to be able
251	   to establish sessions with new neighbors.  This could lead to an
252	   attack where a rogue BGP implementation attempts to open a session
253	   and learns the version information from the responding peer.

[] This is a general vulnerability.  See related comments after the
last paragraph in this section.

255	   The Version Capability MUST be configurable with a vendor-specific
256	   knob to be able to enable or disable the capability.  The vendor
257	   might implement to disable this capability per neighbor.

[minor] The configuration specification is already detailed in §3 --
no need to describe more here.  The only extra functionality (not in
§3) is the ability to disable the capability per-neighbor -- include
it in §3.

259	   It would be safe to enable this for iBGP or inside the same tenant
260	   where you have full control and the BGP speaker is behind the exit
261	   points.

[minor] This paragraph sounds very tentative ("would be safe") and not
explicit about the meaning of "full control" or being "behind the exit
points".  In general I understand what you mean, but it many be too
vague for an RFC.  Take a look at RFC8799, which talks about
"controlled environments" (aka limited domains) -- that might be a
good reference for what you mean above.

[minor] This topic is related to the text already in §3 about
deploying outside a single AS (see my comments there too).
Suggestion: keep these operational considerations in one place.
Perhaps §3 is not ideal -- consider §4 instead.

263	   This capability is NOT RECOMMENDED for eBGP use.

[minor] As mentioned above, put all operational/deployment
considerations in one place.  BTW, this is the only place where eBGP
is used...perhaps the AS-related terminology is better.

265	   Sensitive information leaks can be minimized by using the [RFC5082]
266	   mechanism or firewalls to filter out TCP 179 port from untrusted
267	   networks.  This capability can be disabled per neighbor, thus the
268	   sensitive information can't be disclosed to untrusted neighbors.

[minor] General vulnerabilities.  These two techniques (and other
general suggestions) are covered in rfc7454 (BGP Operations and
Security).  A reference to that document instead of mentioning
specifics that are not exclusive to this extension may be better.

[major] One more thing -- borrowing also from rfc8203 -- add the following:

   This document uses UTF-8 encoding. There are a number of security issues
   with Unicode.  Implementers and operators are advised to review Unicode
   Technical Report #36 [UTR36] to learn about these issues.  UTF-8 "Shortest
   Form" encoding is REQUIRED to guard against the technical issues outlined
   in [UTR36].

Here's the reference:

[UTR36]    Davis, M., Ed. and M. Suignard, Ed., "Unicode Security
           Considerations", Unicode Technical Report #36, August
           2010, <http://unicode.org/reports/tr36/>.

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Thu, 20 Aug 2020 06:28:18 -0700

Alvaro,

Very many thanks for this review.

I won't get into the discussion of whether these are valid points for a
conflict review, but will focus instead on the technical content which is
valuable.

[snip]

> (1) You do a very good job to highlight potential threats in the
> Security Considerations section.
> But you also Normatively recommend (SHOULD) the use of encryption in
> the BGP Session.
> While sensible, there are no Standards Track documents that currently
> do the same.
>
> This recommendation, even if the draft points out that it "is not an
> IETF Standards Track document", can create confusion and potentially
> disrupt other IETF work.

At this point, I don't see that as a problem. This is a recommendation
that *if* you use this extension you should also use encryption. The fact
that no standards track documents recommend encryption means that if you
don't use this extension you are not recommended to use encryption.

Can you supply examples of the confusion or disruption? (It is certainly
not our intention to confuse or disrupt!)

> The threats that you identify are not exclusive to this extension,
> so the solution/mitigation shouldn't be either.

Not sure I follow that. The threat identified is incremental. That is, it
applies to the use of this extension. If the threat also applies to other
pieces of BGP we would hope that the IDR working group addresses them, but
we would not expect this document to address them.

If there are already solutions available that this document should use to
mitigate the threat, then obviously we would want to use them.

> This issue should be easy to -- I suggested alternative text below.

So, response to that in line.

> RECOMMENDED to exclude the Version Capability"), the Capabilities
> Length Overflow (§3.1) handling represents a significant threat to a
> BGP session.
> The recommendations are not enough to prevent the potential
> exclusion of other more critical Capabilities.
> The use of draft-ietf-idr-ext-opt-param could reduce the risk, but may
> result in the same problem.
>
> session where one of the peers supports the Version Capability, I
> believe that this document would require IETF review.
>
> This issue can be addressed by requiring the exclusion of the
> Version Capability (using MUST), *and* talking about the risk in the
> Security Considerations section.

While we consulted about the length limit and the risk of impact on other
Capabilities, and arrived at 64 bytes as a reasonable low to zero risk,
being future-proof is hard. It is unclear, for example, how any new
Standards Track Capabilities would avoid this issue.

However, I would be comfortable with:
- SHOULD be no greater than 64 bytes
- MUST be left out if would constrain inclusion of any other Standards
Track capabilities

At that point, I don't believe it is a security threat.

> See more comments about this in-line in §3.1.
>
>

You are right that all BGP Capabilities are optional. However, I would
like this text to remain to further emphasize that this Independent Stream
work is not something that implementations are required to consider
including.

> 83  and to help minimize operational costs, it is helpful to exchange > 
   the
> [nit] For completeness, it would be nice to have a reference to LLDP/CDP.

Easily done

> [nit] s/except you have/except if you have

ack

> The Version Capability is intended for environments where more
> visibility is needed for troubleshooting purposes.  It is NOT
> RECOMMENDED for use outside a single Autonomous System, or a set of
> Autonomous Systems under a common administration.

If you think that is clearer, then it is OK for me. I believe it covers
confederations and also DCs where each router has a different ASN, so it
would be OK.

> don't re-specify the behavior here.

Yes. This document is allowed to describe the behavior documented in 5492
without using normative language. But it is better to simply say:

An implementation that does not recognize or support the Version
Capability but which receives one will handle it as described in
[RFC5492].

...which is slightly different from your
[snip]
>  Capability but receives one must ignore it, as described in

...because "will" (rather than "must") indicates that the behavior is
pre-ordained.

> [minor] For completeness, please add the following from rfc5492:

Well, for consistency with the previous point, let's not redefine anything
here. So, yours...

>  contains the length of the Capability Value field in octets.

...mine
As defined in [RFC5492], the Capability Length is a one-octet unsigned
binary integer that contains the length of the Capability Value field in
octets.

> [major] s/the entire triple MUST be ignored/the Capability MUST be ignored

I'm not sure this is right, except that maybe you are defining "the
Capability" to be the triple {type, length, value}. Perhaps the answer is
to be even more specific and say...

The Capability Length for the Version Capability MUST be greater
than zero.  A Capability Length value of zero SHALL be treated as an
encoding error and the entire Capability (triple of code, length and
value) MUST be ignored.

> [minor] Please add a forward reference to §3.1.  See more comments

Easily done

> 143  unstructured data and can be formatted in any way that the

Yes. Good point. Either include the Capability Code (which looks like
needless repetition of the definition of a Capability triple), or exclude
the Capability Length (which makes the figure a bit pointless).

> to rfc3639 would be useful here.

Agree that a reference to what UTF-8 is would be wise.

> simply the number of octets?

Author's choice on this one.
If you wanted 'number of characters' you would need a second length field,
and that adds structure to the Capability Value.

> The Version field MUST be encoded using UTF-8.  A receiving BGP
> speaker MUST NOT interpret invalid UTF-8 sequences. This field is not >
NUL terminated.

This looks sensible to me.

> [?] Was the use of draft-ietf-idr-ext-opt-param considered?

Author to respond, but I believe that while this is available, it is seen
as "unlikely to become an RFC any time soon". That would mean that either
the author had to fold it in to this document (which I would think makes
it absolutely IDR work) or sit with a normative reference for ever.

> Version may need a long string...but excluding the Version Capability

I think the authors decided on RECOMMENDED because an implementation
should be free to decide which capabilities are more or less important.
However, as indicated in my response to the comment at the top of this
email, I would be comfortable with:

- SHOULD be no greater than 64 bytes
- MUST be left out if would constrain inclusion of any other Standards
Track capabilities

>  A rogue node can prevent the proper operation of a BGP session, or
>  the advertisement of other Capabilities, by not excluding the Version
>  Capability as required in Section 3.1.  This risk is equivalent to a
>  rogue node simply not advertising a specific Capability and is not
>  new to BGP.

Sorry, but by your own text, this is at best unhelpful. A rogue node can
do anything! A rogue node can decide to omit or lie about capabilities; it
can add new and unknown capabilities that fill up the the attribute; it
can violate any MUST from a protocol spec; it can generate random streams
of bytes.

Adding your text would, I think, not be very harmful, but it gives the
appearance that this protocol extension introduces a new threat. It does
not. So if you wanted something added it would need to say "BGP includes
no protection against rogue or subverted implementations. This
specification does not introduce any security measures to address that
problem." Personally, I don't think that this is the place for a
commentary on the general deficiencies of BGP.

> but of Optional Parameters -- take a look at rfc4271/§4.2.

Oh, this is a splendid point!
And here we have the issue that even modest constraint on the length of
the Capabilities may cause us to run out of space for other Optional
Parameters.

IANA helpfully shows us that there are not many optional parameters
defined
(https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-11)
so this problem is not rampant, but it raises two questions for the
authors:
1. Why a capability code and not an optional parameter?
   (I suspect the registry assignment rules may have a lot to do with
   this!)
2. How do you stop the version capability crowding out other optional
   parameters?

> [minor] There is already a specification in Â§3 about explicit
> Enabling (i.e., turning on) this capability may require a restart of
> any existing BGP sessions and its explicit configuration (Section 3).

Fair enough.

> Capability may have stale information.

Yeah, I have some memory of that being discussed, but can't put my finger
on it. It would be useful to have some text on this case.

> Below is an example from the [FRRouting] implementation showing both
> the received and advertised Version Capability:

Sounds reasonable.

> 195  :~# vtysh -c 'show ip bgp summary failed'

[snip]

> [] I'm not sure what this figure is showing.

Authors should add an explanation or pointer as appropriate

> 217  registry with a subregistry called "Capabilities Codes".
>

Well, perhaps not major?

If you go to https://www.iana.org/protocols and search for "Border Gateway
Protocol (BGP) Parameters" you easily enough find a list of registries of
which one is clearly called "Capabilities Codes".

We can debate (endlessly?) whether the first is a registry and second a
subregistry. I am almost certain that not too many people will worry about
the result of our debate.

> out of place, and may cause unnecessary confusion that could disrupt

As discussed at the top of this email, I don't see how recommending the
use of encryption when this feature is in use impacts other
implementations or deployments of BGP. In no way does this document
provide guidance for regular BGP deployments.

I suspect that TLS might be an available mechanism for protecting BGP
sessions. I have heard people talk about IPsec as an appropriate approach.
Some have claimed MACsec also works (although it seems there are
limitations).

It seems to me that pointing out the threat and recommending a mitigation
is exactly what this document should do.

> 247  causes of faults in the network. Â This can be mitigated by
>      protecting

Agreed. And why is it wrong for this document to observe that the
extension in this document is vulnerable?

It is the job of the security considerations section to consider the
extension and the information it carries, and to set out any additional
threats and vulnerabilities that its use create. Where possible the
section should also describe mitigation.

> information could be gathered by inspecting BGP OPEN messages that
> carry the Version Capability defined in this document.  Furthermore,
> this knowledge may facilitate a number of social-engineering attacks.
>
> provides integrity is used for the BGP session in question, the
> Version Capability can be forged.  Unless a transport that provides
> confidentiality is used, the Version Capability could be snooped by
> an attacker.  These issues are common to any BGP message but may be of
> practices as outlined in Section 6.1 of [RFC6973], as appropriate
> within the deployment context.

I don't have any objection to this new text.

> last paragraph in this section.

Again, while agreeing that this is a general BGP threat, the information
gathered is specific to this document.

> §3) is the ability to disable the capability per-neighbor -- include

I agree to including the per-neighbor configuration in section 3.
I disagree to removing this material from this section as it applies to
the security of the implementation.
Adding a back pointer to section 3 and reducing this text would be fine.
Thus...
The Version Capability MUST be configurable within an implementation as
described in Section 3.

> good reference for what you mean above.

It's the subjunctive.
It can be rewritten as "It is safe..."
Agree that clarifying "full control" would be valuable.

> Perhaps §3 is not ideal -- consider §4 instead.

The authors may consider an Operational Considerations section, however, I
think it critical to the security of an implementation that this material
is at least referenced from the security considerations section.

> 263	 Â  This capability is NOT RECOMMENDED for eBGP use.
>
> considerations in one place.

As above.

> BTW, this is the only place where eBGP

Good point to consider.

> specifics that are not exclusive to this extension may be better.

A reference *as*well*as* the current text would be good.

> This document uses UTF-8 encoding. There are a number of security
> issues with Unicode.  Implementers and operators are advised to review
> Unicode Technical Report #36 [UTR36] to learn about these issues.
> UTF-8 "Shortest Form" encoding is REQUIRED to guard against the
> technical issues outlined in [UTR36].
>
> Here's the reference:
>

That's good text, thanks (and highlights the point that the security
considerations section *should* include descriptions of generic security
concerns (in this case a UTF-8 issue) that are described elsewhere.

Best,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 20 Aug 2020 13:21:30 -0500

On August 20, 2020 at 9:28:42 AM, RFC ISE wrote:

Adrian:

Hi!

...
> don't use this extension you are not recommended to use encryption.

This extension is only present in the OPEN message (1 message), while
a BGP session is (hopefully) long-lived.   Recommending any
transport-related functionality is really a recommendation for the
whole BGP session.

> not our intention to confuse or disrupt!)

TL;DR: The objective is consistency with current practice and
expectations related to BGP documents.

Over the years, the need for "upgrading" BGP's security, specifically
in terms of authentication, integrity and confidentiality has been the
subject of many conversations and reviews, including many from the
SecDir and SEC ADs.  The summary of those discussions has been to not
change the recommendations/requirements in documents specifying
enhancements (like this one), but to do so in the base specification,
which is the one dealing with the specification of the transport for
BGP.

Given that you don't have any objection to the new text I proposed for
the Security Considerations, I think we're settled. :-)

...
...
> - MUST be left out if would constrain inclusion of any other Standards

That works for me too.

...
> commentary on the general deficiencies of BGP.

The SEC Area has been putting some emphasis lately on the effect that
a rogue node can have, related to the specified functionality.  That
is the reason that I suggested the text.

I am ok if the author doesn't decide to include the text above.

...
> 2. How do you stop the version capability crowding out other optional

That's maybe a better way of stating my concern about the ability to
affect the operation of a BGP session...  [The only Optional
Parameters currently used are Capabilities.]

I'm ok with all your other comments and suggestions.

Thanks!

Alvaro.

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Thu, 20 Aug 2020 11:55:12 -0700

Lovely. Thanks for the quick convergence, Alvaro.

We'll wait to see what Donatas makes of all this.

Best,
Adrian

-- 
Adrian Farrel (ISE),
[email-masked]

---

From: Donatas Abraitis <[email-masked]>
Date: Fri, 21 Aug 2020 19:31:50 +0300

Hello Alvaro and Adrian,

thank you for the detailed review. I'll look at that carefully next week.

By the way, should I upload a new version with fixes or send a
generated txt here (or pastebin/gist) to review again before pushing
to draft revision?

-- 
Donatas Abraitis
Systems Engineer
@: [email-masked]
W: www.hostinger.com

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 21 Aug 2020 11:31:01 -0700

On August 21, 2020 at 12:32:01 PM, Donatas Abraitis wrote:

Donatas:

Hi!

> By the way, should I upload a new version with fixes or send a generated
> txt here (or pastebin/gist) to review again before pushing to draft
> revision?

If your changes are in line with what Adrian and I have discussed, I
don't have a problem with uploading a new version.  If you think there
will be a significant deviation, especially on the points I made at
the top, we should talk about it.

The IESG will consider this document on Sep/10, so I would like to
post the result of the conflict review by Sep/4 (so others have time
to review it).  IOW, if you post an update before then, we should be
ok. :-)

Thanks!!

Alvaro.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 21 Aug 2020 21:29:47 +0200

Hi,

> The IESG will consider this document on Sep/10

May I ask why are we skipping normal process to go via IDR with this draft
?

Also looking at latest published version why status of this doc is
"Informational" if essentially this is a protocol extension ?

Last - if this is to be enabled only for iBGP does this mean that we are
endorsing networks which do not know in their NMS what version of operating
systems is deployed on a given network element ? And for manual CLI based
iBGP session troubleshooting how does it help to know the version of route
reflector if problem with received UPDATES or WITHDRAWS can be generated
one iBGP hop behind it ?

Thx,
R.

On Fri, Aug 21, 2020 at 8:31 PM Alvaro Retana <[email-masked]>
wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Fri, 21 Aug 2020 12:30:23 -0700

What Alvaro said.

:-)

Adrian

-- 
Adrian Farrel (ISE),
[email-masked]

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Fri, 21 Aug 2020 12:42:40 -0700

Hello Robert,

> May I ask why are we skipping normal process to go via IDR with this
> draft ?

It's a valid question.

After several attempts, the IDR WG was not apparently willing to adopt
this idea. The chairs confirmed this, and the author brought the work to
the Independent Stream.

Note that on 20191121 I sent mail to IDR ("Cross-check wrt
draft-abraitis-bgp-version-capability") to give a heads-up on this plan.

> "Informational" if essentially this is a protocol extension?

The Independent Stream is not capable of producing Standards Track RFCs.
This "protocol extension" using a FCFS code point is, therefore,
documented in an Informational RFC to describe what has been implemented
and how to use/interoperate with it.

> Last - if this is to be enabled only for iBGP does this mean that we
> are endorsing networks which do not know in their NMS what version of
> operating systems is deployed on a given network element?

I don't think that "we" are endorsing anything. This document is stating
what has been implemented.

We could discuss adding text to say that "In many networks, it might be
expected that the NMS would have full knowledge of the deployed operating
system versions on each router in the network. This mechanism provides a
way to verify that information and operate in the absence of a coordinated
NMS." I'm not sure how helpful such text would be.

> And for
> manual CLI based iBGP session troubleshooting how does it help to know
> the version of route reflector if problem with received UPDATES or
> WITHDRAWS can be generated one iBGP hop behind it?

I'll leave Donatas to answer that one.

Best,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

---

From: Donatas Abraitis <[email-masked]>
Date: Fri, 21 Aug 2020 22:44:15 +0300

endorsing networks which do not know in their NMS what version of operating
systems is deployed on a given network element ? And for manual CLI based
iBGP session >troubleshooting how does it help to know the version of route
reflector if problem with received UPDATES or WITHDRAWS can be generated
one iBGP hop behind it ?

Not only iBGP. It's up to the administration scope. If that's a clos
topology of leaves and spines, most likely there will be eBGP used. Or even
especially routing on the host, or more complicated Kubernetes/Docker
deployments.

-- 

*Donatas Abraitis*
*Systems Engineer*

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 21 Aug 2020 22:08:02 +0200

> especially routing on the host, or more complicated Kubernetes/Docker

Sure not just iBGP but the draft says this: "This capability is NOT
RECOMMENDED for eBGP use."  I realize what you meant to say was that the
draft is "NOT RECOMMENDED" to be used between different operational
domains.

- - -

In any case this is an interesting case of IDR bypass. If this is approved
I can already see a line of other proposals. Where will it bring BGP time
will tell.

My intention is however just to point out that this is a protocol extension
which IDR compliant implementations will need to be aware of.

The document uses a very soft language in a number of places. Example: The
Capability Length SHOULD be no greater than 64.

Bottom line is that there is a lot of people in IDR and/or GROW who think
that we need to exchange such information between BGP peers. I am one of
them. In the past I wrote BGP diagnostic message draft then we merged it
with Advisory Message into BGP Operational Message which was in fact
adopted as IDR WG document
https://tools.ietf.org/html/draft-ietf-idr-operational-message-00

I think BGP (well really OS) version is a useful information, but I do not
think this should be part of BGP Capabilities as an opaque text.

My recommendation here is to add a new message to BGP Operational Message
document and move forward with that more general solution to the problem.
If FRR can support BGP Operational Message we can document it and move one
step closer to IDR LC.

Kind regards,
Robert

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 21 Aug 2020 14:06:19 -0700

On August 21, 2020 at 4:08:33 PM, Robert Raszuk wrote:

[Explicitly cc'ing the WG Chairs.]

Robert:

Hi!  I hope you're doing well.

...
> In any case this is an interesting case of IDR bypass.

Let's please call things by their proper name.  As Adrian already
explained, the draft was initially brought to idr and there seemed to
be no interest in it [1].  The WG hasn't been bypassed, it just wasn't
interested.

Adrian also mentioned this:

=====

=====

If there is now interest in progressing this work then a discussion on
the list is in order.  I'll let the WG Chairs lead it, if needed.

John/Sue:  What is your opinion?  Do we need time to discuss interest in idr?

> If this is approved I can already see a line of other proposals. Where will
> it bring BGP time will tell.

This is an interesting comment given that the WG recently processed
rfc8810 (Revision to Capability Codes Registration Procedures)
dedicating a significant portion of the registry to be assigned using
the First Come First Served procedure, which doesn't even require
technical documentation [rfc8126].   I didn't see any objections on
the list.

> which IDR compliant implementations will need to be aware of.

Just like other Capabilities, it is an optional extension.  rfc5492
already contemplates the existence of unknown or unsupported
Capabilities.

I'll let the WG discuss the rest of your message.

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/search/?q=%22draft-abraitis-bgp-version-capability%22

> document and move forward with that more general solution to the problem. If
> FRR can support BGP Operational Message we can document it and move one step
> closer to IDR LC.

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Fri, 21 Aug 2020 14:14:13 -0700

I think I object to the idea that this is  bypass of IDR.

It is *still* not too late for IDR to pick up this work if they want to
(but it is very close to too late). What I would need to hear (and I
presume Alvaro as the responsible AD) is a clear statement that the WG
*does* want to work on this.

Robert, I read your email as saying that "I want roughly this function,
but I would not do it that way." (Please say if I misread you). That is
certainly possible, and the WG is never expected to approve work without
review and editing, but it is hard for an author who fails to get any
traction to be told much later that there is finally traction but only if
they discard their approach and start again.

Perhaps one of the perils of a FCFS registry is that codepoints are
relatively freely available and without WG control. But it isn't as though
the author did not put this up for review from IDR on several occasions.

Wrt draft-ietf-idr-operational-message, I note that this expired a few
days less than eight years ago. I think it is reasonable to assume that
the WG is not pursuing that idea.

Best,
Adrian

Robert Raszuk wrote:
>> topology of leaves and spines, most likely there will be eBGP used. >>
Or even especially routing on the host, or more complicated
>> Kubernetes/Docker deployments.
>>
>
> RECOMMENDED for eBGP use."  I realize what you meant to say was that
> the  draft is "NOT RECOMMENDED" to be used between different
> operational domains.
>
> - - -
>
> In any case this is an interesting case of IDR bypass. If this is
> approved I can already see a line of other proposals. Where will it
> bring BGP time will tell.
>
> My intention is however just to point out that this is a protocol
> extension which IDR compliant implementations will need to be aware
> of.
>
> The document uses a very soft language in a number of places. Example:
> The Capability Length SHOULD be no greater than 64.
>
> Bottom line is that there is a lot of people in IDR and/or GROW who
> think that we need to exchange such information between BGP peers. I
> am one of them. In the past I wrote BGP diagnostic message draft then
> we merged it with Advisory Message into BGP Operational Message which
> was in fact adopted as IDR WG document
> I think BGP (well really OS) version is a useful information, but I do
> not think this should be part of BGP Capabilities as an opaque text.
>
> My recommendation here is to add a new message to BGP Operational
> Message document and move forward with that more general solution to
> the problem. If FRR can support BGP Operational Message we can
> document it and move one step closer to IDR LC.

-- 
Adrian Farrel (ISE),
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 21 Aug 2020 23:32:16 +0200

Dear Adrian, All,

I think there is a significant difference between documenting that some
extension is useful from stating this is useful and MUST be done this way.

Also I am not sure what Alvaro expects IDR and chairs to do here. To adopt
the draft which insists on using BGP Capabilities to carry a free form text
when there may not be rough consensus to do so ?

Or maybe to take a problem at hand and work together to produce a solution
which may not use BGP Capabilities at all ?

Network audit tools are really cool to have, but just like some recent
attempts to turn BGP into config push is BGP a good protocol to exchange
OS/BGP code version information between peers ? And as I asked and no one
answered what if the problem is caused by 1 session away ?

> the WG is not pursuing that idea.

In my books the document is stable for some time and waiting for
implementations.

It seems rather a norm that some documents take 10+ years to get processed
here. Hint: pls just look at the history of BGP Optimal Route Reflection
document history. So 8 years seems still pretty nominal to me ;)

Cheers,
R.

PS. As to the use of "bypass" term I did not mean to say that this has been
hidden in any form or shape ... quite contrary. WG says this is not good
solution then going around WG is what I call a bypass.

---

From: Alvaro Retana <[email-masked]>
Date: Sat, 22 Aug 2020 05:15:50 -0700

On August 21, 2020 at 5:32:57 PM, Robert Raszuk wrote:

Robert:

Hi!

...
...
> solution then going around WG is what I call a bypass.

Thank you for clarifying.

The Independent Submission Stream can be used (among other things) to
publish ideas that have not been adopted, or even rejected, by the
IETF.  The only IETF involvement is the rfc5742 conflict review, which
is where we are now: in short, the IESG is expected to answer whether
the work conflicts with IETF work, and make a recommendation.  See the
possible outcomes in §3/rfc5742.

Note that at this point, the work is not part of the IETF.

Even if not required by rfc5742, I decided to technically review the
document and post my comments to this list.  In reviewing the mail
archive, I didn't see an explicit call for adoption or direction from
the chairs to take the document to the ISE, just lack of interest (not
a lot of comments). So I also sent a separate note to the idr-chairs
asking for their opinion.

What do I expect?  I first expect an answer from the Chairs -- from my
last message:

   John/Sue:  What is your opinion?  Do we need time to discuss interest in
   idr?

I don't expect adoption, or for the WG to take on related work...or
not.  It is for the Chairs to lead any discussion about adoption or
anything else, hence my question above.  Apart from that, I'm sure
that the ISE will appreciate any comments that can make the document
better.

Going back to rfc5742.  Assuming that my comments (in this thread) are
addressed, I consider that the work is (obviously!) related to idr,
but that it doesn't prevent publishing (in the Independent Submission
stream).  I currently don't see active work that explicitly[*]
addresses the same type of functionality.  I would be happy to be
corrected and for the Chairs to confirm.

Thanks!

Alvaro.

[*] The Operational Message could include similar functionality...I'm
sure there could be other approaches.  However, I don't see that
documented anywhere or active discussion on the list about it.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 22 Aug 2020 14:39:00 +0200

Hi Alvaro,

Just one additional comment here.

> In reviewing the mail
> a lot of comments).

+

 However, I don't see that
> documented anywhere or active discussion on the list about it.

This draft has been discussed in IDR on Aug 2nd 2019 and functionality
discussed was considered useful by number of WG members. I have actually
never seen any push back from IDR chairs not to adopt this work sent to
the list.

Ref: https://mailarchive.ietf.org/arch/msg/idr/zHNioWl24mdTthQA0O4OatZ2uy4/

In fact below message proves the opposite - comment from chairs about
publication of Operational Message:

Ref: https://mailarchive.ietf.org/arch/msg/idr/RmObg6bEhwbs2BEy-l5CnDBKPbc/

As I see from emails there was commitment to join the work, review and
resubmit BGP Operational Message:

https://mailarchive.ietf.org/arch/msg/idr/yorRQMPTm8RRc8L5ZPbX04cHRr0/

We were hoping that authors of  bgp version capability could join that as
well. Well it apparently never moved. I was under impression that they gave
up on it.

So I am a bit surprised to see this proposal is coming now via a bit
different doors.

Kind regards,
Robert.

---

From: Donatas Abraitis <[email-masked]>
Date: Tue, 25 Aug 2020 07:09:32 +0300

Hello, Alvaro,

thank you clarifying this to me. I'll update the document as per your recommendations. 

> On 2020-08-20, at 21:21, Alvaro Retana <[email-masked]> wrote:
>

---

From: John Scudder <[email-masked]>
Date: Fri, 28 Aug 2020 03:04:45 +0000

(Individual contributor hat on, one of the chairs will follow up tomorrow.)

Hi Adrian,

A couple of points —

>> On Aug 20, 2020, at 9:29 AM, RFC ISE (Adrian Farrel) <[email-masked]> wrote:
> ...

Actually it’s passed WGLC and the only hurdle remaining is for me (or someone) to clean up the implementation report before it’s shipped off for publication. This is fairly high on my to-do list. In my view it’s actually *likely* to become an RFC in the near future.

> (https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml*bgp-parameters-11__;Iw!!NEt6yMaO-gk!TSP1xJLtCVzr536UQhjnXHW6dt7cLC-OL8cHzqOIX5Mj8anMiLqgJVjms6HwiQ$ )

It’s my view that there will likely never be another Optional Parameter defined. The property they have of causing a session reset if not supported is unpleasant for operational purposes. With 20/20 hindsight, we probably should have just bit the bullet and deprecated Optional Parameters, redefining them as something more like Capabilities, but instead we carefully fit Capabilities into the pre-existing Optional Parameters, and we’re stuck with it now. For practical purposes, Capabilities are BGP’s optional parameter mechanism, and the RFC 4271 Optional Parameters field is vestigial. 

I trust that answers your question (1), and I think (2) has already been covered both above and elsewhere in the thread.

—John

---

From: John Scudder <[email-masked]>
Date: Fri, 28 Aug 2020 18:30:04 +0000

On Aug 27, 2020, at 11:04 PM, John Scudder <jgs=[email-masked]<mailto:jgs=[email-masked]>> wrote:

one of the chairs will follow up tomorrow

(Co-chair hat on)

TL;DR: I’d prefer a different way forward, as a WG document, but I don’t see a basis for asking ISE not to publish if that’s the author’s preference. I do have a couple comments at the bottom that I’d like addressed.

Longer version:

I went back and reviewed the list traffic on this draft. Here’s the timeline I see:

- Donatas told the WG about the draft on August 2, 2019. This kicked off a thread that ran until August 20, 2019.
- In that thread, some people liked the draft, some didn’t, some suggested using draft-ietf-idr-operational-message to achieve similar functionality.
- The author never asked the list, or chairs, to adopt the draft as a WG item, so we didn’t do a formal call. In retrospect, we chairs should have been more proactive about this, since I see Donatas has only posted to the list one other time, which should be a hint that he might not be completely familiar with how we run the WG.
- Be that as it may, on November 21, three months after the previous thread trailed off, Adrian told the list Donatas had requested ISE publication. That was a second missed opportunity for the chairs to say “ahem”.

There was also some private traffic, in which Donatas sought guidance from the chairs and Adrian. I think maybe there was an in-person conversation between Adrian and me as well, that eventuated into Adrian’s November note to IDR.

If I had it to do over again, I would have stepped in after the August thread and encouraged Donatas to offer it as a WG document if that was his desire. I’d have provided feedback of that nature to Donatas’ unicast message. I’d also have stepped in after Adrian’s November message and said similar.

But I don’t have it to do over, and here we are. Donatas and Adrian now have sunk cost in publishing on the ISE stream. I also don’t know for certain what motivated Donatas to walk away after what, to me, was a fairly friendly and productive WG mail thread last August; I speak of this more a couple paragraphs down.

I don’t think it’s out of the question to adopt the work in IDR even at this late date; indeed there seems to be some interest in the problem space. My *guess* (and it is only a guess) is that the WG would end up preferring an approach that looks more like operational-message, though, and less like version-capability. I base this on the fact that the WG has been fairly steadfast in declining to bung strings into miscellaneous messages. I can think of several examples where it was proposed, and only one example where we’ve actually done it — RFC 8203, and I think the only reason that prevailed was that the session is already doomed in that case, so it’s easier to stomach doing something messy.

So, if Donatas is wedded to the exact implementation documented in draft-abraitis, then it is true, he shouldn’t offer it as a WG contribution, since that would hand change control to the WG. In that case, if the capability is to be shipped anyway, it’s better to document it with an ISE publication than to not document it. My impression from the mail I’ve reviewed is that this is the case.

On the other hand, if this was a misunderstanding and Donatas thought he’d been rejected and that’s why he took his document to Adrian… Donatas, you haven’t been rejected, you just didn’t ask in the way we were expecting to hear, and we chairs didn’t do a good job of encouraging your contribution. Sorry for that.

In short, I agree with Robert’s message of August 22, 2020. Procedurally, though, I don’t think IDR has a veto pen: we chose to give the registry an FCFS range, and by definition we don’t have a veto over that. The pointy end of permissionless innovation is, we don’t get to deny permission. I don’t think draft-abraitis would harm the BGP protocol, it’s just not the way the WG might choose to solve the problem. So, if Donatas wants to publish it as is (and it seems he does), then it’s settled.

I do have a couple further remarks about the draft, though:

First, I see that section 3 mentions that

   Although this document is not an IETF Standards Track document,

While I’m glad this is mentioned, I think it would be worth saying something similar in the abstract and introduction, instead of burying it in the middle. For example, “This document is not the product of an IETF working group and is not an IETF Standards Track document". Perhaps this is a usual thing to do with ISE stream documents anyway, and it would come later in the editing process, in which case sorry for the noise.

Second, a comment about naming: I find “version” to be a terribly confusing name, since BGP has a version number of its own. I would prefer almost any other name, for example “description” or the wordier “software-version”. “Version” on its own is ambiguous in a way I don’t think is helpful for anyone. (Feedback like this would have come as a matter of course, if the document had been a WG document.)

Thanks,

—John

---

From: Donatas Abraitis <[email-masked]>
Date: Fri, 28 Aug 2020 22:10:30 +0300

>- The author never asked the list, or chairs, to adopt the draft as a WG
item, so we didn’t do a formal call. In retrospect, we chairs should have
been more proactive about this, since I see Donatas has only posted to the
list one other time, which should be a hint that he might not be completely
familiar with how we run the WG.

Hello John,

unfortunately yes, I'm not familiar with the process.

>Second, a comment about naming: I find “version” to be a terribly
confusing name, since BGP has a version number of its own. I would prefer
almost any other name, for example “description” or the wordier
“software-version”. “Version” on its own is ambiguous in a way I don’t
think is helpful for anyone. (Feedback like this would have come as a
matter of course, if the document had been a WG document.)

Agree about changing naming. "software-version" or "daemon-version" sounds
better than just "version". I thought about that as well (confusion with
BGP version).

P.S. I just want to double-check, because sorry, don't know the process,
what should I do actually now with this draft?

Thank you, guys.

On Fri, Aug 28, 2020 at 9:30 PM John Scudder <[email-masked]> wrote:

> On Aug 27, 2020, at 11:04 PM, John Scudder <
> jgs=[email-masked]> wrote:
>
>
> TL;DR: I’d prefer a different way forward, as a WG document, but I don’t
> see a basis for asking ISE not to publish if that’s the author’s
> preference. I do have a couple comments at the bottom that I’d like
> addressed.
>
> Longer version:
>
> - In that thread, some people liked the draft, some didn’t, some suggested
> using draft-ietf-idr-operational-message to achieve similar functionality.
> - The author never asked the list, or chairs, to adopt the draft as a WG
> item, so we didn’t do a formal call. In retrospect, we chairs should have
> been more proactive about this, since I see Donatas has only posted to the
> list one other time, which should be a hint that he might not be completely
> familiar with how we run the WG.
> - Be that as it may, on November 21, three months after the previous
> thread trailed off, Adrian told the list Donatas had requested ISE
> publication. That was a second missed opportunity for the chairs to say
> “ahem”.
>
> There was also some private traffic, in which Donatas sought guidance from
> the chairs and Adrian. I think maybe there was an in-person conversation
> between Adrian and me as well, that eventuated into Adrian’s November note
> to IDR.
>
> If I had it to do over again, I would have stepped in after the August
> thread and encouraged Donatas to offer it as a WG document if that was his
> desire. I’d have provided feedback of that nature to Donatas’ unicast
> message. I’d also have stepped in after Adrian’s November message and said
> similar.
>
> But I don’t have it to do over, and here we are. Donatas and Adrian now
> have sunk cost in publishing on the ISE stream. I also don’t know for
> certain what motivated Donatas to walk away after what, to me, was a fairly
> friendly and productive WG mail thread last August; I speak of this more a
> couple paragraphs down.
>
> I don’t think it’s out of the question to adopt the work in IDR even at
> this late date; indeed there seems to be some interest in the problem
> space. My *guess* (and it is only a guess) is that the WG would end up
> preferring an approach that looks more like operational-message, though,
> and less like version-capability. I base this on the fact that the WG has
> been fairly steadfast in declining to bung strings into miscellaneous
> messages. I can think of several examples where it was proposed, and only
> one example where we’ve actually done it — RFC 8203, and I think the only
> reason that prevailed was that the session is already doomed in that case,
> so it’s easier to stomach doing something messy.
>
> So, if Donatas is wedded to the exact implementation documented in
> draft-abraitis, then it is true, he shouldn’t offer it as a WG
> contribution, since that would hand change control to the WG. In that case,
> if the capability is to be shipped anyway, it’s better to document it with
> an ISE publication than to not document it. My impression from the mail
> I’ve reviewed is that this is the case.
>
> On the other hand, if this was a misunderstanding and Donatas thought he’d
> been rejected and that’s why he took his document to Adrian… Donatas, you
> haven’t been rejected, you just didn’t ask in the way we were expecting to
> hear, and we chairs didn’t do a good job of encouraging your contribution.
> Sorry for that.
>
> In short, I agree with Robert’s message of August 22, 2020. Procedurally,
> though, I don’t think IDR has a veto pen: we chose to give the registry an
> FCFS range, and by definition we don’t have a veto over that. The pointy
> end of permissionless innovation is, we don’t get to deny permission. I
> don’t think draft-abraitis would harm the BGP protocol, it’s just not the
> way the WG might choose to solve the problem. So, if Donatas wants to
> publish it as is (and it seems he does), then it’s settled.
>
> While I’m glad this is mentioned, I think it would be worth saying
> something similar in the abstract and introduction, instead of burying it
> in the middle. For example, “This document is not the product of an IETF
> working group and is not an IETF Standards Track document". Perhaps this is
> a usual thing to do with ISE stream documents anyway, and it would come
> later in the editing process, in which case sorry for the noise.
>
> Second, a comment about naming: I find “version” to be a terribly
> confusing name, since BGP has a version number of its own. I would prefer
> almost any other name, for example “description” or the wordier
> “software-version”. “Version” on its own is ambiguous in a way I don’t
> think is helpful for anyone. (Feedback like this would have come as a
> matter of course, if the document had been a WG document.)
>
> Thanks,
>
> —John
>

-- 

*Donatas Abraitis*
*Systems Engineer*

---

From: John Scudder <[email-masked]>
Date: Fri, 28 Aug 2020 19:31:25 +0000

On Aug 28, 2020, at 3:10 PM, Donatas Abraitis <[email-masked]> wrote:
> 
> P.S. I just want to double-check, because sorry, don't know the process, what should I do actually now with this draft?

It really depends on you.

If you want to proceed forward with the ISE publication, that depends on Adrian and his colleagues. From my point of view, there’s nothing to stop it. 

If you do want to offer it to IDR as a WG document, we’d be happy to work with you on that. Here’s a short précis of procedure, pros, and cons.

- You tell the chairs you’d like to request WG adoption of your document.
- The chairs initiate a discussion on the list, customarily two weeks are given for people to provide their input about whether to adopt it or not.
- The expectation when a document is adopted as a WG draft is that the WG wants to work on the problem, and considers the document a good starting point. It is common, even usual, for the details to change as the WG works on the document though. 
- I imagine part of the discussion would be whether to resurrect operational-message and use that as the basis for a solution instead. One of the comments that came up last August was the idea of hollowing out operational-message to make it a framework only, so that it would be less intimidating to implement when using it for a small extension like yours.

At the end of the process, the chairs judge whether the “rough consensus” is for the WG to take the work on, or not. If the document is adopted, the WG has change control over the document, formally speaking — what this means practically, is that the author needs to take into account what the WG consensus is, he doesn’t just make the decisions on his own. The next formal step after adoption, is working group last call (“WGLC”) where the authors say “we’re done” and the chairs judge whether the WG agrees. Once that’s done, the draft goes to the IESG to become an RFC (there are several more details I’m skipping over).

The con of engaging in this process is it’s more demanding of your time (and patience) than simply proceeding ahead with ISE, and you might end up having to negotiate a quite different solution than you currently have. The pro is that you’d end up getting a lot more review and help, and hopefully would end up with a more robust and general solution, and one that has community consensus and is an actual IETF standard.

I hope that helps. 

Thanks,

—John

---

From: Donatas Abraitis <[email-masked]>
Date: Fri, 28 Aug 2020 22:37:08 +0300

Thanks, John, for this explanation.

> If you do want to offer it to IDR as a WG document, we’d be happy to work with you on that. Here’s a short précis of procedure, pros, and cons.

I would love to continue with IDR. Could you help me and tell me what
actions do I need to do at first?

---

From: John Scudder <[email-masked]>
Date: Fri, 28 Aug 2020 20:39:09 +0000

Yep. I’ll follow up with you unicast.

—John

> On Aug 28, 2020, at 3:37 PM, Donatas Abraitis <[email-masked]> wrote:
> 
> [External Email. Be cautious of content]
> 
>