Early Review of draft-ietf-idr-last-as-reservation-03
review-ietf-idr-last-as-reservation-03-opsdir-early-van-de-velde-2014-04-14-00

Dear All,

This is the requested early review of draft-ietf-idr-last-as-reservation-05

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.

These comments were written primarily for the benefit of the operational
area directors.

This document is: Ready with nits

Review notes:

1. Introduction

This section explains that IANA reserved both last ASN of 16-bit and 32-bit
number space. The introduction mentions that these numbers border on private
use numbers, however that there is no definition or reservation description. 
While description is given later in the document, I do feel that the
introduction would be more complete with a 1 line high level overview of its
intended usage case.

4. Operational Considerations

s/Operators SHOULD NOT use these Last ASNs as if they are Private Use ASNs or
for any other purpose./ Operators SHOULD NOT use these Last ASNs for any other
purpose or as Private Use ASNs./

<>start<>
Operators that choose to do filtering of Private Use ASNs within the AS_PATH
and AS4_PATH attributes SHOULD also filter these Last ASNs. <>end<>

Why only mention like this when filtering private ASN's? it should always be
filtered, when or when not private ASNs are used... It would be simpler from
operational perspective to have a single recommendation for both instances.

5. Implementation Consideration

<>Start<>
However, implementations MAY generate a local warning message indicating
improper use of a reserved ASN. <>end<>

I think that for operational simplicity this should be a stronger
recommendation SHOULD, because if they are used, then the intended network
architecture will breack somewhere...

Brgds,
G/