Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

["Sriram, Kotikalapudi" <[e-mail]>]

>> And even if we had not decoupled those two, just because you might
>> be authorized to announce 102::/16 to a peer, that is different than
>> saying that you actually announced it.
>point taken
>randy 

I agree that the solution should not merely rely on the presence of a validating ROA.
But there is some more detail here that is worth looking into. The path was fully signed 
and assume all signatures are valid. Then clearly the origin AS actually announced it.
The question or ambiguity is: Did the origin AS announce 1.2.0.0/16 (v4) or 102::/16 (v6)?
The ROA has AFI information, but the signed update does not (currently).
 https://tools.ietf.org/html/rfc6482#section-3.3   
    “Within the ROAIPAddressFamily structure, addressFamily contains the
    Address Family Identifier (AFI) of an IP address family.  This
    specification only supports IPv4 and IPv6.  Therefore, addressFamily
    MUST be either 0001 or 0002.” 

Hence, as Keyur has surmised, there is a possibility that the ROA can help resolve the ambiguity here.
But the ambiguity would still persist if the same origin AS happens to have ROA(s) for 
both prefixes 1.2.0.0/16 (v4) and 102::/16 (v6)  (though the probability is extremely small).
So, yes, a robust solution calls for something more than a validating ROA.
The ambiguity goes away if the AFI (of the announced prefix) is included by the origin AS 
on the wire as well as in the sequence of octets that are signed.

Sriram