Re: [Idr] Shepherd initial report on RFC8203bis

Susan Hares <> Thu, 16 April 2020 10:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C2173A140B; Thu, 16 Apr 2020 03:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.447
X-Spam-Level: *
X-Spam-Status: No, score=1.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LV3vfJ2Ojhun; Thu, 16 Apr 2020 03:41:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4BD053A1410; Thu, 16 Apr 2020 03:41:36 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: Susan Hares <>
To: 'John Scudder' <>
References: <079f01d51dc6$00d6b9a0$02842ce0$> <>
In-Reply-To: <>
Date: Thu, 16 Apr 2020 06:41:31 -0400
Message-ID: <002001d613db$97eb63c0$c7c22b40$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01D613BA.10DB9880"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQK/uSZT6gTRrFPcyfzZCbml8vb+ZQKO2WhKppPN8QA=
Content-Language: en-us
X-Antivirus: AVG (VPS 200415-0, 04/15/2020), Outbound message
X-Antivirus-Status: Not-Tested
Archived-At: <>
Subject: Re: [Idr] Shepherd initial report on RFC8203bis
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Apr 2020 10:41:39 -0000



Thank you for the changes.  This draft is ready to go. 


Sue Hares 


From: Idr [] On Behalf Of John Scudder
Sent: Wednesday, April 15, 2020 5:01 PM
To: Hares Susan
Subject: Re: [Idr] Shepherd initial report on RFC8203bis


(Coauthor hat on) 


Hi Sue,


I’ve uploaded -06 which I think resolves your issues. The idnits issue is a little involved but the summary is “idnits is being too picky”, I go into more detail below.


On Jun 8, 2019, at 2:47 AM, Susan Hares <> wrote:


Status:  Almost ready,  3 required editorial and need for implementation report revision. 




Issues:  key editorial things for IESG submission need to be addressed: 


1)      RFC8203 must be mentioned in the introduction as well as current references (top of front page, Abstract)



2)      NITS need to be resolved


  found: Need for different boiler plate or resolution on generation 


  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may

     have content which was first submitted before 10 November 2008.  If you

     have contacted all the original authors and they are all willing to grant

     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore

     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 

     (See the Legal Provisions document at

      <> for more information.)


If this is in error and you are using XML conversion, please inquire on xml2rfc tool list. 


I don’t think there’s a BCP 78 problem and I don’t think there’s an xml2rfc problem. (There’s kind of an idnits problem, see next paragraph.) Let me explain, although please imagine a chorus chanting “I am not a lawyer and this is not legal advice” in the background. BCP 78 says we (the authors) grant the IETF Trust various rights, including to produce derivative works, blah blah. Now, if our document was itself a modification of a previous document, we might not be the only authors and might not have authority to grant those rights. But, although our header says “Updates: 4486” it doesn’t actually include text from RFC 4486, certainly not text beyond that which would be allowed by fair use. As such, I don’t think we need Enke or Vincent to sign off. I think it’s also the case that this determination is on us as authors to make, not on the IETF. 


Actually I’m not sure why idnits applies the BCP 78 check against the updated documents. I’ve raised this with Henrik, but I don’t think it needs to hold up progress of our document — a diligent document shepherd might ask the authors “are you sure?” which you’ve now done, and thank you for that. I, for one, am sure. As we both know, idnits is just a suggestion, it’s not required to run clean, it’s guidance for the shepherd.


By the way, for some reason idnits runs clean when I submit the document, but if I run standalone idnits it throws the error you’ve mentioned. Not sure why that is. Maybe the submission mode suppresses miscellaneous warnings, or maybe it’s a bug.

3)      IN section: 5.  IANA Considerations


        Old:  /Cease Notification message subcodes/

       New: /BGP Cease NOTIFICATION message subcodes/


    The actual registry name is in the new text.  




4)      Implementation report for OPENBSD and BIRD need to be completed or explained. 

(yes/no) in each category is not understandable.  


I removed the implementation section entirely, since it was supposed to be removed by the RFC Editor anyway and since we have an implementation report available at