Re: [Isis-wg] Gen-art LC review draft-ietf-isis-tlv-codepoints-00

Jari Arkko <> Thu, 07 August 2014 01:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DCCA41A03B4; Wed, 6 Aug 2014 18:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LBKTHvXQcxt7; Wed, 6 Aug 2014 18:24:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 843531A03AE; Wed, 6 Aug 2014 18:24:21 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 894022CC5F; Thu, 7 Aug 2014 04:24:20 +0300 (EEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yVCVUQGGpfDp; Thu, 7 Aug 2014 04:24:16 +0300 (EEST)
Received: from [] ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id DDD182CC48; Thu, 7 Aug 2014 04:24:12 +0300 (EEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_E7D44622-CCFC-47BA-81F6-70D4CE672784"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <>
In-Reply-To: <>
Date: Thu, 7 Aug 2014 13:24:08 +1200
Message-Id: <>
References: <> <> <> <> <> <>
To: Robert Sparks <>
X-Mailer: Apple Mail (2.1878.6)
Cc: "Les Ginsberg \(ginsberg\)" <>, General Area Review Team <>, "" <>, "" <>, The IESG <>
Subject: Re: [Isis-wg] Gen-art LC review draft-ietf-isis-tlv-codepoints-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Aug 2014 01:24:24 -0000

(Resending due to incorrect e-mail address - please respond to this instead.)

Thank you very much for your review, Robert.

>>>>> Thanks for assembling such a clearly written document.
>>>>> The shepherd writeup should have discussed _why_ this document is
>>>>> intended for Proposed Standard.
>>>>> There is no protocol definition here, and nothing to progress on the
>>>>> standards ladder. This is, instead,
>>>>> primarily defining process. Why isn't this being progressed as a BCP?
>>>> The document does two things:
>>>> 1)It updates some registries for sub-TLVs defined at
>>> codepoints.xhtml
>>>> As these changes are modifying the format (not the content) of registries
>>> used by a number of standards track RFCs it needs to be a standards track
>>> document.
>>> I don't believe that follows. A BCP could update these documents as well.
>> The registries define the codepoints which are sent on the wire by IS-IS implementations. This is absolutely essential for interoperability. I fail to follow your reasoning that a change to such a registry falls into the BCP bucket.
>> That said, I don't really care about the category - my goal in writing this draft is to satisfy the process requirements to get what amount to editorial changes to the registry done. In this matter I am happy to follow the recommendations from IANA/IESG, Gen-ART, etc. So let's not argue - rather please build consensus with your peers in IANA/IESG as well as the ADs and I will happily agree so long as it accomplishes the original goal.
> Yes - the IESG can steer this at this point.

With regards to the document-as-ps issue, I think we can observe that new or changed IANA considerations have been done under various document classifications. I personally can not get worked over whether this is a BCP or a PS, albeit, as Pete notes, "Slightly weird to have this be Standards Track.”. I think having the texts clarified as Adrian suggested in his Discuss is probably the most worthwhile thing we can do here.