Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04

[Randy Bush <[e-mail]>]

> This document creates an IANA registry for the "BGP origin validation
> state".

which is highly inappropriate, as the three and only three states are
cast in stone.  this should be removed if we're going to progress the
document.

> 2) Documenting change on BGP decision process changes: Section 3.
> Basically the origin validation happens before any other policy
> applied. This goes beyond the iBGP community but even for stand-alone
> routers. In this sense, you can implement RPKI in a device without
> modifying any existing policy description.

and this was codified in rfc 6811.  now you get to compare the two,
because any inconsistency would be bad.

> 3) Documentation of non-standard BGP communities: Over the years, we
> have seen a number of attempts to document and standardise providers
> communities with less than great results. One particularly use case
> (that I suffered) is when you have to merge two networks due to an
> acquisition, standardised communities are very helpful.

last para of rfc 7115 sec 5

   Validity state signaling SHOULD NOT be accepted from a neighbor AS.
   The validity state of a received announcement has only local scope
   due to issues such as scope of trust, RPKI synchrony, and management
   of local trust anchors [LTA-USE].

> And lets not forget: Running Code: Last but not least…the draft has
> been delayed more than what it should and several implementations
> (including two from Cisco) has running code + documentation +
> training. As we are pushing to improve adoption of RPKI, I rather
> spend time adding the missing pieces that removing what is not
> broken…although the need may not be obvious for everyone.

actually, code removal is not an evil, quite the opposite.

but, as i said

> i do not support publication.  i am not strongly opposed.  it's just
> one more bit of ietf work that is not obviously needed.

randy