Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05

[Stephen Kent <[e-mail]>]

Rob,

On 9/28/12 10:17 AM, Rob Austein wrote:
> At Fri, 28 Sep 2012 09:54:01 -0400, Stephen Kent wrote:
>>>>    4.1.  Originating a New BGPSEC Update
>>> ...
>>>>       In particular, this AS number MUST match the AS number in
>>>>       the AS number resource extension field of the Resource PKI end-entity
>>>>       certificate(s) that will be used to verify the digital signature(s)
>>>>       constructed by this BGPSEC speaker.
>>> "The" or "an"?   Is it legal for the EE certificate to cover more RFC
>>> 3779 resources than just a single ASN?
>> yes, an EE cert can contain multiple ASNs, if they were allocated to the
>> cert holder by the same parent.
> I know that RFC 3779 allows multiple ASNs, having implemented it. :)
and I wrote it, so ...
>
> What I'm asking is whether it was Matt's intent to restrict BGPSEC to
> requiring that only a single ASN be certified in the relevant EE
> certificate.  I do not recall any such restriction during earlier
> discussions of this protocol, which is why I flagged it.
OK, that was not clear from you question.
>
>>>>    6.1.  Algorithm Suite Considerations
>>> ...
>>>>       To this end, a mandatory algorithm suites document will be created
>>>>       which specifies a mandatory-to-use 'current' algorithm suite for use
>>>>       by all BGPSEC speakers [12].  Additionally, the document specifies an
>>>>       additional 'new' algorithm suite that is recommended to implement.
>>> Badly phrased, unless the real intent here is to say that we're going
>>> to pick both the current and next algorithms right off the bat, which
>>> seems unlikely to me.   I think it would be more correct to say that
>>> we will specify an initial mandatory algorithm suite, and, once we
>>> have some idea of what the next algorithm should be, we will publish
>>> a series of updated documents phasing in the new one and (eventually,
>>> years later) phasing out the old one.
>> that would be consistent with the alg migration strategy described in
>> draft-ietf-sidr-algorithm-agility-07
> I assume (please correct if wrong) that your comment refers to my
> suggested rephrasing being consistent with the algorithm migration
> strategy.
>
yes.

Steve