Re: [core] [Anima] documenting SID usage in IETF specification

Carsten Bormann <cabo@tzi.org> Wed, 12 September 2018 16:15 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9324130DF3; Wed, 12 Sep 2018 09:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3U9aOTrf_ga; Wed, 12 Sep 2018 09:15:03 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E22130E43; Wed, 12 Sep 2018 09:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w8CGExa1027469; Wed, 12 Sep 2018 18:14:59 +0200 (CEST)
Received: from client-0131.vpn.uni-bremen.de (client-0131.vpn.uni-bremen.de [134.102.107.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 429Rh32SLkzDXmK; Wed, 12 Sep 2018 18:14:59 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <50f58c78b6825ce1cdbc33ea852c3145@bbhmail.nl>
Date: Wed, 12 Sep 2018 18:14:58 +0200
Cc: Andy Bierman <andy@yumaworks.com>, anima@ietf.org, Core <core@ietf.org>
X-Mao-Original-Outgoing-Id: 558461697.009642-e1d796edda0c37b966c3d736002b0eea
Content-Transfer-Encoding: quoted-printable
Message-Id: <84F58F84-4637-4D65-8F86-8E86B346528F@tzi.org>
References: <17342.1536697549@localhost> <622CDA79-7BE4-4A71-BFF7-0C80F63A1556@tzi.org> <CABCOCHTrjYZmK4e+L7pj=V=sWxg97jw2AFGen2PFe7ceBrB7bg@mail.gmail.com> <50f58c78b6825ce1cdbc33ea852c3145@bbhmail.nl>
To: peter van der Stok <consultancy@vanderstok.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/yvuInm8rt1D7AsDksxL0U4Hkack>
Subject: Re: [core] [Anima] documenting SID usage in IETF specification
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Sep 2018 16:15:10 -0000


> On Sep 12, 2018, at 17:15, Peter van der Stok <stokcons@bbhmail.nl> wrote:
> 
> Hi all,
> 
> The numbering of the SIDs in our case should be as stable as possible after publication as RFC.
> A permanent assignment of the numbers, like the content-format numbers, would be very much appreciated.
> Using the same already allocated numbers for other RFCs would be quite disastrous.

Yes, I think that part is clear.

What Andy pointed out is that we also need to have an idea of how to evolve a draft in a way that minimizes damage from changing those numbers during the development of that draft.  So we need to start allocating and managing SID numbers early in their lifetime, at least from the point of time when a draft is becoming an “implementation draft” (as opposed to just an idea that wants to be discussed).  That is not something we have traditionally done with IANA registrations, which are traditionally considered a scarce resource and thus should only be assigned to finished (or near-finished, hence “early allocations”) protocols.

My proposal would be:

— have a more explicit way of designating drafts as Implementation Drafts.   Basically, any SIDs allocated before that are without protection,  but once we have an Implementation Draft, the SIDs used in that will not be re-used.  (Intermediate versions between Implementation Drafts would again have any new SIDs in unprotected state until another Implementation Draft is declared.)

— have a way to include the SID file in the document (draft, RFC).  This is not beautiful, but unless we invent another representation for that information, that is the interchangeable form.  (If we do invent another representation, maybe we should always use that?)

Grüße, Carsten


> 
> Maintenance of (part of) the comi.space by a organisation like IANA could be a possibility.
> 
> Peter
> Andy Bierman schreef op 2018-09-12 01:32:
> 
>> 
>> 
>> On Tue, Sep 11, 2018 at 3:12 PM, Carsten Bormann <cabo@tzi.org> wrote:
>> On Sep 11, 2018, at 22:25, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>> > 
>> > SHOULD ietf-core-sid say something about this?
>> 
>> Yes, we should have a common way of handling SID allocations in RFCs.
>> 
>> draft-ietf-core-sid sounds like a natural way to place this, but what goes into what document is often a question of who has time to write something at a particular point in time.  So let's discuss this with the authors.
>> 
>> In any case, this probably should stay at the level of a suggestion more than prescribing a normative way of doing things — the conventions we use for this may evolve faster than the rest of the technical content of draft-ietf-core-sid.
>> 
>>  
>> You probably want to make a clear distinction between Internet Drafts with volatile SID assignments
>> and RFCs with permanent SID assignments.
>>  
>> Do you want early implementation (of modules using SID)  to be as painful as possible or as seamless as possible?
>> Renumbering SID assignments may be extremely disruptive to actual deployments.
>> Correctness of a SID file within a source document is not the same thing as correctness of all SID files
>> across an entire administrative domain.
>>  
>> I agree the administration of SID assignments is out of scope for CORE WG but punting
>> the problem to vendors or operators will not be good enough.
>>  
>>  
>>  
>> Grüße, Carsten
>>  
>>  
>> Andy
>>  
>> 
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>> 
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima