Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

[Christopher Morrow <[e-mail]>]

Hey there folks,
It looks, to me, like we both went far over time on decision making
for this draft, but ALSO on the good side had some good conversation
about improvements/misses/missed-understandings.

So, first I think we pull this draft back from the edge of publication
and address at least one point which seems to have gotten some fair
time
at the mic:
"Should the ASPA content be AFI specific? or AFI Agnostic?"

It seems to me that there are both sides being discussed with what
looks like a reasonable end at: "AFI Agnostic please"
This makes some sense to me, at least, since generally though we MAY
have disjoint (not the same?) forwarding paths
for v4/v6 we probably have reasonable ideals that our v4/v6
transit/customer relationships are fairly well aligned. It may
be the case that there are folks with this sort of deployment, they
should be able to publish correct ASPA records, I believe.

I think a side effect of this decision (AFI agnostic ASAP) is that we
need to rethink/redo a bit of 8210bis, which I think
was shipped at IESG for publication 'just recently' :(

Does the above make enough sense to roll forward with? :)
Are there complaints you'd like to swing my way? :)

-chris

On Tue, May 2, 2023 at 6:45 AM Martin Hoffmann <[e-mail]> wrote:
>
> Hi Sririam!
>
> Sriram, Kotikalapudi (Fed) wrote:
> >
> > >My observation was mostly about the fact that this is (now: was)
> > >rather quite hidden in the somewhat complex document structure.
> > >Calling it out in the profile draft should be good enough for RP
> > >implementers to at least be aware of something going on and having
> > >to read up on it some more.
> >
> > Just to be sure, would you be fine now with the proposed copying
> > of the ASPA registration related sections (Sec. 2 and Sec. 4)
> > from the verification draft into the profile draft?
>
> I think keeping them in the verification document is better. To my
> mind, the split between the two documents should be: profile contains
> everything an implementer of relying party software or a (simply) CA
> needs to be aware of, while verification has everything related to BGP,
> i.e., how does ASPA verification work and what should an AS publish.
>
> Profile would then be limited to parsing and validating
> published objects itself and transforming their content into a
> validated payload set.
>
> Keeping both publishing recommendations and ASPA path verification
> together in one document makes sense to me, since in order to fully
> understand the consequences of publishing certain ASPA objects, you
> need to understand how path verification works.
>
>   -- Martin
>
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops