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

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Martin,

Thanks. Just trying to close the loop. 

>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?

Sriram  

________________________________________
From: Martin Hoffmann <[e-mail]>
Sent: Friday, April 28, 2023 1:38 PM
To: Sriram, Kotikalapudi (Fed)
Cc: [e-mail]; [e-mail]; Claudio Jeker
Subject: Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

Hi Sriram!

Sriram, Kotikalapudi (Fed) wrote:
> Hi Martin,
>
> >Now, from the split into two documents, I conclude that as someone
> >implementing an RPKI relying party software, you aren’t expected to
> >read the verfication draft -- and will likely miss this subtlety. So,
> >presumably, the conversion rules should be in the profile draft.
>
> We'll make sure that it is clear in the verification draft, and
> also, some sections related to ASPA registration and VAP-SPAS
> creation will be repeated in the profile draft so that
> the latter is self-contained.
>
> Regarding augmentation of VAP-SPAS with AS 0 SPAS for
> the case of a CAS that has neglected to include one of the
> AFIs in the ASPA, that is a thing that concerns the
> verification algorithm. Keeping that in mind, do you feel that
> it might be OK if we simply take care of it on the router side
> after the RTR ASPA PDUs have been received? Details follow.

I don’t think that’s a good solution. The RTR payload format is as it
is now to make things as easy as possible for routers that implement
the most simple data structure. The RP software has to do merging of
multiple ASPAs, anyway, so it is quite easy for it to convert an empty
set into an AS0-only set.

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.

> If not, then we need to talk about changing the processing
> on the RTR cache server side or changing the RTR ASPA PDU format
> (like what Claudio has been talking about). That would call
> for a change in 8210-bis.

While I think that redesigning the ASPA RTR PDU would be a good idea --
if there’s always one PDU per address family they might as well be
merged into one --, that draft is already in the publishing queue and
there is at least one released real world implementations (and someone
would need to yell “stop” real soon to avoid a second one), so I
suspect that ship has sailed.

  -- Martin