Section 5 requires that an EE certificate be used for the signing of the RPSL object. An EE certificate must contain an SIA extension that points to an RPKI signed object (RFC 6487 [4.8.8.2]). The draft does not define a profile for a new type of object, or specify an existing one that may be used instead. There are a number of ways to deal with this: for example, by defining a new profile and changing the signature URL to suit, or by amending RFC 6487 such that object pointers in EE certificates are optional. Section 4 specifies sets of attributes that must be signed. 'org' is included as one of these attributes for the as-block, inet[6]num, and route[6] object types. However, 'org' is not defined in either of the principal RPSL RFCs (2622 and 4012), and there are current implementations (e.g. APNIC's) that do not support it. I think the references to 'org' should be omitted. Section 4 specifies 'signature' as an attribute that must be signed. 'signature' can appear multiple times in a single object, where e.g. two different resource holders sign a route[6] object. Given that the text doesn't explicitly state that only the newest 'signature' must be signed, it would appear to require that any extant 'signature' attributes be signed as well. That in turn would prevent previous signers from re-signing the object independently of the subsequent signers. I think the text should be changed so that only the new signature attribute need be signed. Section 2.4 requires that "the Internet number resources present in [RFC3779] extensions of the certificate referred to in the "c" field of the signature must cover the resources in the primary key of the object". This means that it's not possible to sign a route[6] object for a route where one resource holder has the ASN and another the prefix. In revision 8 (and earlier), the possibility of there being multiple signatures, each with a certificate covering a subset of the primary key resources, was explicitly permitted. I think that the previous text here should be restored. (The above points were the product of much discussion of this draft with Tim and Oleg from RIPE, not that I'm speaking for them. We were able to write interoperable prototype signer/validator implementations, so the document is in pretty good shape on the whole.) -Tom