Re: [RTG-DIR] [Idr] Rtgdir last call review of draft-ietf-idr-bgp-prefix-sid-21

["Acee Lindem (acee)" <[e-mail]>]

No Mas... Although the use cases for flags relating to these specific TLVs should be few and far between, I anticipate there will be continued FCFS registry attack trepidation. I'll change them to expert review. 
Thanks,
Acee 

On 6/14/18, 2:36 PM, "Donald Eastlake" <[e-mail]> wrote:

    Hi,
    
    See below
    
    On Wed, Jun 13, 2018 at 9:02 PM, Acee Lindem (acee)
    <acee=[e-mail]> wrote:
    >
    > Hi Bruno,
    >
    > Thanks for your review - you’ve raised some heretofore undetected ambiguities that need to be rectified. I've taken most of your comments. I plan to publish an update including all the comments that I've incorporated (tonight or tomorrow morning).
    >
    > See replies inline.
    >
    > On 6/13/18, 1:53 PM, "Bruno Decraene" <[e-mail]> wrote:
    >
    >     Reviewer: Bruno Decraene
    >     Review result: Has Nits
    >
    >     ...
    >
    >
    >     ==========================
    >     Major Issues:
    >
    >     § IANA consideration
    >
    >        "This document also requests creation of the "BGP Prefix-SID Label-
    >        Index TLV Flags" registry under the "Border Gateway Protocol (BGP)
    >        Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid.
    >        Initially, this 16 bit flags registry will be empty.  Flag bits will
    >        be allocated First Come First Served (FCFS) consistent with the BGP-
    >        SID TLV Types registry."
    >
    >     IMHO a registry of only 16 possible entries seems very small for a FCFS policy.
    >     Anyone would be able to deplete it in minutes. (cf RFC 8126 "It is also
    >     important to understand that First Come First Served really has no
    >     filtering."). Is this really the intention of the WG? (Actually I'm wondering
    >     what would be the monetary value of such a flag on the black market... If zero,
    >     this means that the flag are useless. If non-zero, the benefit may be worth the
    >     trouble)
    >
    >     Same comment for the "BGP Prefix-SID Originator SRGB TLV Flags" registry.
    >
    > I don't believe we need to consider attacks on the FCFS registries. You've got to believe that IANA will only consider legitimate requests. If not, it seems the whole concept of FCFS is flawed.
    
    While I greatly respect IANA and the quality of service they provide,
    the main idea of the transition of authority for protocol parameters
    from John Postel ( aka "King John") to IANA was to make the IANA task
    as objective and clerical as possible, deferring all required
    judgements to experts or standards actions or whatever as specified in
    the registry in question. The theory that "IANA will only consider
    legitimate requests" implies, unless "legitimate request" is
    specifically defined in this draft (which pretty much negates FCFS),
    judgements that IANA is not contracted for and not supposed to be
    making.
    
    I have a lot of sympathy for the view that the concept of FCFS is
    flawed and should almost always be Expert Review instead. But, there
    are some cases of essentially infinite values available (e.g., a
    multi-precision integer parameters or lengthy string values). And, in
    any case, where a registry has tens of thousands of values that are
    usually allocated one or a few at a time, there is one saving
    paragraph in RFC 8126 as follows:
    
       IANA always has the discretion to ask the IESG for advice or
       intervention when they feel it is needed, such as in cases where
       policies or procedures are unclear to them, where they encounter
       issues or questions they are unable to resolve, or where registration
       requests or patterns of requests appear to be unusual or abusive.
    
    But I think it is unwise to depend on this. Note that IANA has NO
    authority to refuse a registration for FCFS, they could only delay
    responding and refer it to the IESG if they happen to notice it as
    being suspicious. And I don't know if there has ever been a case where
    IANA has done this. As it says in RFC 8126:
    
       It is also important to understand that First Come First Served
       really has no filtering.  Essentially, any well-formed request is
       accepted.
    
    Thanks,
    Donald
    ===============================
     Donald E. Eastlake 3rd   [phone] (cell)
     155 Beaver Street, Milford, MA 01757 USA
     [e-mail]
    
    >     ...
    >
    > Thanks,
    > Acee