Subject: [sidr] BGPSec RFC status

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Apr 2016 14:17:40 -0400

I didn't attend the IETF meeting, but I did listen to the Wednesday SIDR 
session, at
which the issue was raised as to whether the BGPSec RFC should be 
standards track
or experimental.

I believe standards track is the right approach here. This document has been
viewed as standards track since we began work on it long ago. It is the 
successor
to the origin validation standards, addressing the residual 
vulnerabilities that
persist based on that use of the RPKI. From the perspective of promoting 
adoption
it is critical that this remain a standards track document; router 
vendors will
be unlikely to devote resources to design and implementation if BGPsec 
is labeled
experimental. I agree that this is new technology, but I heard that we 
already have
a  couple of implementations already, and we may discourage others from 
continuing to
work on BGPSec implementations if we downgrade the status of the RFC. 
The design has
evolved to accommodate real-world routing deployment topics such as the 
role of IXPs
and AS migration. In my long experience in the IETF experience, the 
level of attention
to these an analogous details makes BGPsec a very solid candidate for 
standards track
publication.

Steve

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Apr 2016 14:36:07 -0400

I didn't attend the IETF meeting because I as chairing another session in another room at the same time. During that session the issue was raised as to whether the BGPSec RFC should be standards track or experimental.  I strongly support publication on the standards track. There are already two interoperable implementations, so I think that all of the criteria for advancement on the standards track have been met before we even get published at the proposed standard.

I believe that publication as experimental will greatly delay deployment, which will already take a very long time.  Let’s mover forward on this journey and get some real experience.

Russ

---

From: Declan Ma <[email-masked]>
Date: Thu, 14 Apr 2016 13:14:46 +0800

I think BGPsec should be Standards Track.

ISPs and router vendors won’t take BGPsec seriously if it is published as an Experimental RFC.

We came a long way here from S-BGP and so much time and so many efforts by many have been spent on BGPsec. The community need some real experience.

Di

ZDNS

---

From: Geoff Huston <[email-masked]>
Date: Fri, 15 Apr 2016 06:20:28 +1000

> On 14 Apr 2016, at 4:17 AM, Stephen Kent <[email-masked]> wrote:
> 
> I didn't attend the IETF meeting, but I did listen to the Wednesday SIDR session, at
> which the issue was raised as to whether the BGPSec RFC should be standards track
> or experimental.
> 

I was in the room, but did not speak to this topic. 

> I believe standards track is the right approach here.

I consulted the oracle of RFC2026 and read the following:

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

This seems to fit well, including the caveats at the end.

On the other hand:

  The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).

Which seems to fall short.

The exercise of RFC publication of BGPSec is more than archival, and the process
has been much more than a cursory exercise of coordination with the SIDR WG. While
BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow’s Internet, that
future uncertainty applies to most of the IETF’s work, and that consideration 
should not preclude its publication as a Proposed Standard, as I interpret RFC2026.

Geoff

---

From: "Russ White" <[email-masked]>
Date: Thu, 14 Apr 2016 19:51:11 -0400

I wanted to address a point that's been brought up a number of times in this thread -- the contention "if we don't go standards track, people aren't going to be motivated to deploy this." There is an opposite argument to be made in this line of logic -- "if we do go standards track, there will no work done on any alternate solution -- because there is a standard in place -- and if the standard ends up being undeployable (which is, after 15+ years of work, still true), then we will do nothing."

Overall, I find it difficult to assess the risk in either direction, so I think these two tend to equal one another out. OTOH, if we are going to go standards track, it needs to be with the specifically called out understanding that these drafts are not the final answer -- that the IETF doesn't consider this the ultimate solution for the problem at hand. 

>    interest to be considered valuable.  

What is the meaning of "community interest." From which community, specifically? Does "community interest" include actual deployment in commercial networks, or ... ?? I'm not pretending to know the answer here, just asking the question.

:-)

Russ

---

From: Randy Bush <[email-masked]>
Date: Fri, 15 Apr 2016 09:26:06 +0900

snmp, netconf, yang, ...  heck even cops played in the space

when your so-bgp, 15 years in the non-making, is mature as a document
set, with two or more implementations, i'll support it for standards
track, no problem.  i am not desperate enough to sabatoge the work of
others to move my work forward.

randy

---

From: "Russ White" <[email-masked]>
Date: Thu, 14 Apr 2016 21:05:11 -0400

> when your so-bgp, 15 years in the non-making, is mature as a document set,
> with two or more implementations, i'll support it for standards track, no
> problem.  i am not desperate enough to sabatoge the work of others to
> move my work forward.

Wow -- care to prove that accusation? Or have we gotten to the point in the
IETF where personal accusations are a normal, everyday, substitute for
actual discussion? This sort of personal abuse is what turns people away
from the IETF, and reduces our value as a community. This is just wrong,
Randy, and you know it is.

My point is simple -- the "no-one will use it" argument washes either way,
so there needs to be some other grounds for deciding -- it's not a useful
argument in either direction, honestly. Which throws us back to what
"standards track" actually means. On that score, I'm not certain what the
terms mean, so I asked for clarification on what the wording actually means.

:-)

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 15 Apr 2016 00:18:00 -0300

On Thu, Apr 14, 2016 at 10:05 PM, Russ White <[email-masked]> wrote:

> set,
​<co-chair-hat>​

​to be very clear, I don't think that rock tossing helps here.. in fact I
think it's distracting to the question asked. (original question I mean)
let's not toss rocks please. (either of the 2 folk on To: nor other folk on
the -list)​
​</hat>​

> terms mean, so I asked for clarification on what the wording actually
​I don't know exactly either, but this from 2026:

"​   A Proposed Standard specification is generally stable, has resolved
   before it advances."

doesn't:
  1) say anything about the 'Final and Ultimate Solution'
  2) that other work can't be done

In fact the last sentence implies that more work could be done and that
it's NOT the final solution.

​let's please keep to the question. I do think discussion of this topic is
interesting, to me at least, and useful for the group. My personal opinion
is that PS seems like the right answer still, even after all these years.

-chris
<co-chair>​

---

From: Rob Austein <[email-masked]>
Date: Thu, 14 Apr 2016 23:55:49 -0400

At Fri, 15 Apr 2016 00:18:00 -0300, Christopher Morrow wrote:
> 
> I don't know exactly either, but this from 2026:
> 
> "   A Proposed Standard specification is generally stable, has resolved

Exactly.  Enough people seem to think this is a promising approach to
merit PS status.  The fact that there are also people who don't want
to use it doesn't change that.  Go for PS and move on.

---

From: t.petch <[email-masked]>
Date: Fri, 15 Apr 2016 11:19:02 +0100

----- Original Message -----
From: "Geoff Huston" <[email-masked]>
To: "sidr" <[email-masked]>
Sent: Thursday, April 14, 2016 9:20 PM

standards track

Geoff

I agree that Proposed Standard is the right, the obvious choice, but in
another context, it might matter that the oracle is dead, buried by
RFC7127

"  A Proposed Standard specification is stable, has resolved known
   design choices, has received significant community review, and
   appears to enjoy enough community interest to be considered valuable.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard will have no known technical omissions with
   respect to the requirements placed upon it.  Proposed Standards are
   of such quality that implementations can be deployed in the Internet.
   However, as with all technical specifications, Proposed Standards may
   be revised if problems are found or better solutions are identified,
   when experiences with deploying implementations of such technologies
   at scale is gathered.
"

which I find a somewhat looser requirement and so unlikely to affect the
outcome of this discussion.

Tom Petch

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

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 15 Apr 2016 14:09:58 -0400

All,

Thanks to Geoff and Tom for pointing out that we do have definitions of what PS and Experimental mean. If those definitions are wrong (c.f. some of the comments relating to whether some designation does or doesn't advance some greater good or agenda) is not a question for SIDR to decide -- if you don't like the definitions, propose revisions to RFCs 7127 and/or 2026.

Based on the definitions provided in those two RFCs, BGPSEC fits into the PS bucket. If there is debate about whether it falls short of any of the RFC 7127 criteria for PS, the best time to have raised that would have been at WGLC but of course there's still IESG review and IETF LC, so there's ample time for anyone who wants to be heard. 

$0.02 from this individual WG member,

--John

> On Apr 13, 2016, at 2:17 PM, Stephen Kent <[email-masked]> wrote:
> 
> viewed as standards track since we began work on it long ago. It is the successor
> to the origin validation standards, addressing the residual vulnerabilities that
> persist based on that use of the RPKI. From the perspective of promoting adoption
> it is critical that this remain a standards track document; router vendors will
> be unlikely to devote resources to design and implementation if BGPsec is labeled
> experimental. I agree that this is new technology, but I heard that we already have
> a  couple of implementations already, and we may discourage others from continuing to
> work on BGPSec implementations if we downgrade the status of the RFC. The design has
> evolved to accommodate real-world routing deployment topics such as the role of IXPs
> and AS migration. In my long experience in the IETF experience, the level of attention
> to these an analogous details makes BGPsec a very solid candidate for standards track
> publication.
> 
> Steve

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 17 Apr 2016 09:35:15 -0700

> On Apr 15, 2016, at 11:09, John G. Scudder <[email-masked]> wrote:
> 
> All,
> 

Not liking something very much is not a great basis for experimental status vs ps as opposed to yes vs not at this time.  IMHO when we look at BGPSec we've go to ascertain whether we can live with the consequences of various actors outside the IETF participants deciding it's cooked enough to deploy, use, require and so on. 

From my vantage point it's about time, not because we're done, but the documents are not going to get much more cooked, we've accumulated significant infrastructure around it, and the marketplace needs to have as say on deployment and this is how we signal that.

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Tue, 19 Apr 2016 22:31:22 +0000

+1 with Standard Track.

The question could have been relevant six years ago and we may not have
debated it that much then. Today, we are clearly beyond experimental draft
definition and we do not want to stop people working on the topic.

Roque

On 14/04/16 22:20, "sidr on behalf of Geoff Huston" <[email-masked]
on behalf of [email-masked]> wrote:

>BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow¹s
>Internet, that
>future uncertainty applies to most of the IETF¹s work, and that
>consideration

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 20 Apr 2016 10:01:17 +0200

> On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) <[email-masked]> wrote:
> 
> +1 with Standard Track.

+1

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 22 Apr 2016 11:40:44 -0400

There's been some good discussion on this, i think we (chairs) didn't
expect the list to jump on this without some prompting... but it's nice to
see :)

So, in service of 'coming to a decision' I think we should debate/discuss
for another bit, and close discussion Fri 4/29/2016 - April 29th 2016.

thanks!
-chris

---

From: Warren Kumari <[email-masked]>
Date: Mon, 25 Apr 2016 14:53:20 +0000

... and another +1.
W