[sidr] [fixed] Confirming that the last interim reflects working group consensus

[Matthew Lepinski <[e-mail]>]

Note: My apologies for the previous, incomplete, email. I accidently hit
"Send" before the message was complete.

At the interim meeting in Amsterdam, we had a discussion on open issues in
draft-ietf-sidr-bgpsec-protocol-05.
Here is a link to the slides that I presented at that meeting. (
http://www.ietf.org/proceedings/interim/2012/09/29/sidr/slides/slides-interim-2012-sidr-6-1.pdf
)

I would like to confirm on the list that the discussions at the last
interim reflect the consensus of the working group.
In this message, I list for each open issue, my understanding of the sense
of the room in Amsterdam. If you believe that for any of these issues that
I may be misunderstanding the consensus of the working group, please start
a discussion on the list as soon as possible. I am currently working on the
-06 version of the protocol draft, therefore, if you have an objection to
anything in this message, please raise it promptly.

--------------------------------

1.1. In referring to the data that is typically carried in the AS_PATH
attribute, I will a phrase similar to "The sequence of ASes through which
an update passes".

1.2. With regards to transport security, the document will specify "SHOULD"
use transport security to protect BGP sessions. However, the document will
NOT specify (as either a MUST or a SHOULD) and specific transport security
mechanism.

1.3. There is no information in the current Editor's Notes that is worth
retaining in future versions of the document

2.1. The document will recommend that if there is a failure to negotiate
BGPSEC in a session with a peer, the BGP-speaker should fall back to BGP-4
without BGPSEC (instead of closing the session).

2.2. Unless someone comes to the list with a use-case for including SAFI in
the BGPSEC capability advertisement, I will remove SAFI from the BGPSEC
capability advertisement.

2.3. BGPSEC support and 4-byte ASN support are negotiated separately.
However, the document will explicitly state that if 4-byte ASN support is
not negotiated, then implementations shall consider BGPSEC to have not been
negotiated.

2.4. The document should specify two separate BGP considerations: one for
receiving BGPSEC, and one for sending of BGPSEC.

3.1. I will shorten the name of the BGPSEC_PATH_SIGNATURES attribute to
BGPSEC_PATH attribute.

3.2. BGPSEC will not put Router_ID on the wire as part of the BGPSEC_PATH
attribute.

3.3. My impression of the sense of the room in Amsterdam was that a
majority of people were leaning towards removing the Additional_Info field
form the BGPSEC_PATH attribute. However, several individuals spoke in favor
of improving Additional_Info to be a more general extension mechanism. In
the absence of discussion on the list, I will remove Additional_Info.
However, I can see both sides of this issues and so I would be happy to see
productive discussion of this on the list.

3.4. After discussion at the interim,  I believe there is no issue here. I
may add another pointer to the ops document if I can find a useful place to
do so.

3.5. I will make sure the document is consistent throughout on the the
issue of length fields. All length fields will include octets used to
express the length itself.

4.1. When originating an update message within an AS. Whenever BGPSEC is
negotiated on the i-BGP session, updates sent in this will be sent with a
null BGPSEC_PATH attribute instead of a AS_PATH

5.1. I will change the names of the validation states to be "Valid" and
"Not Valid". For now I am going to stay with two validation states. If you
have a good use-case for three validation states, please bring it to the
list.

5.2. There was no resolution to the issue of error handling at the interim.
The options seem to be: (1) Normative reference to 4271; (2) Normative
reference to the IDR error-handling draft; or (3) We pick a particular
mechanism for error handling such as "treat as withdrawal", "drop session",
or "drop update".
Note: This is an area where guidance from the chairs would be very useful
to the document editor!

5.3. The issue of deferred validation seemed to be a rat hole we want to
avoid. The next version of the document will have less text on deferred
validation. (In particular phrases like "as soon as possible" seem not to
be helpful). The working group chairs will help the document authors get
some implementer eyes on the -06 version of the document. If we get
feedback that there is additional guidance on deferment that would be
useful, we can always add something after Atlanta.

5.4.  I will shrink the text on edge validation by combining the 2nd and
3rd sentence shown on the slide. In particular, I will avoid the phrase
"MAY be conveyed via iBGP" and will instead go with something like "MAY be
conveyed via some mechanism".

5.5. The protocol document will be silent on the issue of using the
validation state. This type of issue will be left entirely to the
bgpsec-ops document

5.6. I will add text to the document specifying that when RPKI state
changes the router will re-run policy on all affected updates. I will look
to 4271 to see if I can find any guidance in writing this text on
re-evaluation of received updates.

5.7. I believe that a normative reference to rpki-rtr-keys draft. It was
not clear to me whether an informative reference to rpki-rtr-keys is
needed. However, based on discussion in Amsterdam, it seems that an
informative reference to rpki-rtr-keys might be helpful.