Re: [Idr] Shepherd initial report on RFC8203bis

[John Scudder <[e-mail]>]

(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 <[e-mail]<mailto:[e-mail]>> wrote:

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

https://datatracker.ietf.org/doc/draft-ietf-idr-rfc8203bis/shepherdwriteup/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Drfc8203bis_shepherdwriteup_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=-eMiHgO7gZ2rxAxYRS3bm9Z5nxp_82wcWTD3F0StqUA&s=UqaOsFnBpI5njqg-b95CU-rWXt6-8P4OMxkDR7V_vmo&e=>

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)

Done.

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
     https://trustee.ietf.org/license-info 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.

Done.

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 https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis

Thanks,

—John