[sidr] Implementer inputs requested (Fw: SecDir Review of draft-ietf-sidr-bgpsec-protocol-20)

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

Russ Housley had suggested these changes (#1 and #2 below) as part of his SecDir review.

But he also suggested to me to put it out on the mailing list so that

implementers in particular and anyone having an opinion can have a say.


Russ's comment:

Minor:

#1

In Section 3.2, the Signature Length within the Signature Segment does

not count the length field itself.  It seems that all of the other

length values in this specification count the size of the length too.

Consistency will avoid implementation errors.

Russ's comment:

Minor:

#2

Section 2.1 says:

    ...  The BGP speaker

    sets this bit to 0 to indicate the capability to receive BGPsec

    update messages.  The BGP speaker sets this bit to 1 to indicate the

    capability to send BGPsec update messages.

It seems a bit wasteful to repeat the whole capability for each

direction.  Wouldn't it be better to follow the example used in

other capability definitions (such as RFC 7911) by using one of the

unassigned bits?  The Send/Receive pair of bits would have these

semantics:

    This field indicates whether the sender is (a) able to receive

    BGPsec update messages from its peer (value 1), (b) able to send

    BGPsec update messages to its peer (value 2), or (c) both (value 3)

    for the address family identified in the AFI.

[Sriram] Observation: Two implementations exist and

they were shown to interoperate at the IETF-97 in Seoul.

The changes would cause those implementations to make code modifications.

Sriram