Extended BGP Administrative Shutdown Communication
draft-ietf-idr-rfc8203bis-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-01-05
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-12-23
|
08 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-12-15
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-12-03
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-12-02
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-12-02
|
08 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-11-30
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-11-30
|
08 | (System) | RFC Editor state changed to EDIT |
2020-11-30
|
08 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-11-30
|
08 | (System) | Announcement was received by RFC Editor |
2020-11-30
|
08 | (System) | IANA Action state changed to In Progress |
2020-11-27
|
08 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-11-27
|
08 | Cindy Morgan | IESG has approved the document |
2020-11-27
|
08 | Cindy Morgan | Closed "Approve" ballot |
2020-11-27
|
08 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-11-27
|
08 | Alvaro Retana | Ballot approval text was generated |
2020-11-25
|
08 | Alissa Cooper | [Ballot comment] Thanks for addressing my DISCUSS point. As a courtesy, please respond to the Gen-ART review. |
2020-11-25
|
08 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2020-10-14
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-10-14
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-10-14
|
08 | Jakob Heitz | New version available: draft-ietf-idr-rfc8203bis-08.txt |
2020-10-14
|
08 | (System) | New version approved |
2020-10-14
|
08 | (System) | Request for posting confirmation emailed to previous authors: Alexander Azimov , Job Snijders , John Scudder , Jakob Heitz |
2020-10-14
|
08 | Jakob Heitz | Uploaded new revision |
2020-10-08
|
07 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: David Mandelberg. Sent review to list. |
2020-10-08
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-10-07
|
07 | Barry Leiba | [Ballot comment] It would help if the document said, right up in the Introduction, that the purpose of this is to increase the valid length … [Ballot comment] It would help if the document said, right up in the Introduction, that the purpose of this is to increase the valid length of the Shutdown Communication to 255 octets, up from 128, because 128 turned out not to be enough for translation of reasonable strings into some languages, such as Russian. Such a statement might have made it clearer to the IESG, and perhaps to other reviewers, and will likely help other readers understand why this update is being made. To respond to Alissa's comment about what we might do to avoid this in future is that it's correct that an Internationalization review probably would not have picked up that 128 octets might not be enough for, say, Russian translation of common messages. I guess we could try doing sample translations before settling on maximum field lengths. I suspect that the effort is likely not worth it, given how infrequently this has turned out to be a problem so far. I don't see other I18N issues with this document. I have one text suggestion, as this point has been confusing to people in the past: OLD Note that when the Shutdown Communication contains multibyte characters, the number of characters will be less than the length value. NEW Note that UTF-8 often encodes a single Unicode character as multiple octets. When the Shutdown Communication contains such multibyte characters, the length value (in UTF-8 octets) will be greater than the number of Unicode characters. END |
2020-10-07
|
07 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2020-10-07
|
07 | Alissa Cooper | [Ballot comment] Please respond to the Gen-ART review. For the IESG: it would be good to discuss a bit if there is some process we … [Ballot comment] Please respond to the Gen-ART review. For the IESG: it would be good to discuss a bit if there is some process we can use to avoid this kind of oversight (that occurred with RFC 8203) in the future. i18ndir didn't exist when it was published, but even if it had I'm not sure we would have caught this. |
2020-10-07
|
07 | Alissa Cooper | Ballot comment text updated for Alissa Cooper |
2020-10-07
|
07 | Alissa Cooper | [Ballot discuss] "If a Shutdown Communication longer than 128 octets is sent to a BGP speaker that implements [RFC8203], then that speaker … [Ballot discuss] "If a Shutdown Communication longer than 128 octets is sent to a BGP speaker that implements [RFC8203], then that speaker will treat it as an error, the consequence of which is a log message. For this reason, operators would be wise to keep shutdown communications to less than 128 octets when feasible." I have a similar question to what Éric asked. Doesn't the above mostly undercut the value of doing this bis at all? If operators can't expect longer messages to be understood, will they implement some kind of policy logic or heuristics to decide when to try to send them and when not? Otherwise, under what circumstances will they send them? Was it considered to instead add a new subcode to the BGP Cease NOTIFICATION subcode registry to capture this case (admin reset or shutdown with long shutdown message)? That way at least those who want to use it can differentiate between recipients that don't support RFC 8203, those that do, and those that support longer communications. I'm not at all steeped in BGP so I'm happy to drop this if it's unworkable, but I wanted to ask. |
2020-10-07
|
07 | Alissa Cooper | [Ballot comment] For the IESG: it would be good to discuss a bit if there is some process we can use to avoid this kind … [Ballot comment] For the IESG: it would be good to discuss a bit if there is some process we can use to avoid this kind of oversight (that occurred with RFC 8203) in the future. i18ndir didn't exist when it was published, but even if it had I'm not sure we would have caught this. |
2020-10-07
|
07 | Alissa Cooper | Ballot comment and discuss text updated for Alissa Cooper |
2020-10-07
|
07 | Alvaro Retana | Notification list changed to Susan Hares <shares@ndzh.com>, aretana.ietf@gmail.com from Susan Hares <shares@ndzh.com> |
2020-10-07
|
07 | Alissa Cooper | [Ballot discuss] "If a Shutdown Communication longer than 128 octets is sent to a BGP speaker that implements [RFC8203], then that speaker … [Ballot discuss] "If a Shutdown Communication longer than 128 octets is sent to a BGP speaker that implements [RFC8203], then that speaker will treat it as an error, the consequence of which is a log message. For this reason, operators would be wise to keep shutdown communications to less than 128 octets when feasible." I have a similar question to what Éric asked. Doesn't the above mostly undercut the value of doing this bis at all? If operators can't expect longer messages to be understood, under what circumstances will they send them? I'm not at all steeped in BGP operations, but was it considered to instead add a new subcode to the BGP Cease NOTIFICATION subcode registry to capture this case (admin reset or shutdown with long shutdown message)? That way at least those who want to use it can differentiate between recipients that don't support RFC 8203, those that do, and those that support longer communications. |
2020-10-07
|
07 | Alissa Cooper | [Ballot comment] For the IESG: it would be good to discuss a bit how we can avoid this kind of oversight (that occurred with RFC … [Ballot comment] For the IESG: it would be good to discuss a bit how we can avoid this kind of oversight (that occurred with RFC 8203) in the future. |
2020-10-07
|
07 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2020-10-06
|
07 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-10-06
|
07 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-10-05
|
07 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-10-05
|
07 | Robert Wilton | [Ballot comment] Hi, I found this short document to be easy to read and understand, so thank you for that. One minor nit, which you … [Ballot comment] Hi, I found this short document to be easy to read and understand, so thank you for that. One minor nit, which you are free to take or leave: 2. Shutdown Communication 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code 6 | Subcode | Length | ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ / ... Shutdown Communication ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It would be nice to link the "Error Code 6" back to its definition of "Cease". E.g. this could be done in the preceding paragraph 'Error Code 6 ("Cease")', by defining the Error Code field below the packet diagram (e.g. as is done for the Subcode field). Regards, Rob |
2020-10-05
|
07 | Robert Wilton | Ballot comment text updated for Robert Wilton |
2020-10-05
|
07 | Robert Wilton | [Ballot comment] Hi, I found this short document to be easy to read and understand, so thank you for that. One minor nit, which you … [Ballot comment] Hi, I found this short document to be easy to read and understand, so thank you for that. One minor nit, which you are free to take or leave: 2. Shutdown Communication 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code 6 | Subcode | Length | ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ / ... Shutdown Communication ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It would be nice to link the "Error Code 6" back to its definition of "Cease". E.g. this could be done in the preceding paragraph (Error Code 6 "Cease"), by defining the Error Code field below the packet diagram (e.g. as is done for the Subcode field). Regards, Rob |
2020-10-05
|
07 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-10-05
|
07 | Warren Kumari | [Ballot comment] Thanks to Dan for the OpsDir reivew. |
2020-10-05
|
07 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2020-10-02
|
07 | Benjamin Kaduk | [Ballot comment] Thank you for this clear and well-written document. Just a couple minor comments; no reply necessary. Section 4 If a Shutdown Communication … [Ballot comment] Thank you for this clear and well-written document. Just a couple minor comments; no reply necessary. Section 4 If a Shutdown Communication with an invalid UTF-8 sequence is received, a message indicating this event SHOULD be logged for the Could we say "invalid or non-shortest-form-encoded UTF-8 sequence"? I had started a comment on section 2 about the error handling, but then I saw that there was already an error handling section! Section 7.2 Some die-hards might argue that the "SHOULD include methods such as syslog" promotes RFC 5424 to a normative reference, but I won't make a big deal about it. |
2020-10-02
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
2020-10-02
|
07 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-10-02
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-10-02
|
07 | Éric Vyncke | [Ballot comment] Thank you for this short and easy to read document. Non-blocking comment/question: I really wonder what is the use of this document (message … [Ballot comment] Thank you for this short and easy to read document. Non-blocking comment/question: I really wonder what is the use of this document (message of 0-255 octets) vs. RFC 8203 (message of 0-127 octets) especially when using the same code points... 128 octets is already a long message in ASCII (less of course in UTF-8) and there is no way to know whether the receiving BGP speaker supports this document. I.e., except within a domain, there is little use of this document. What did I get wrong ? Regards -éric |
2020-10-02
|
07 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-09-29
|
07 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-09-29
|
07 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-09-24
|
07 | Cindy Morgan | Placed on agenda for telechat - 2020-10-08 |
2020-09-24
|
07 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2020-09-24
|
07 | Alvaro Retana | Ballot has been issued |
2020-09-24
|
07 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2020-09-24
|
07 | Alvaro Retana | Created "Approve" ballot |
2020-09-18
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-09-18
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-09-18
|
07 | Jakob Heitz | New version available: draft-ietf-idr-rfc8203bis-07.txt |
2020-09-18
|
07 | (System) | New version approved |
2020-09-18
|
07 | (System) | Request for posting confirmation emailed to previous authors: John Scudder , Job Snijders , Alexander Azimov , Jakob Heitz |
2020-09-18
|
07 | Jakob Heitz | Uploaded new revision |
2020-07-14
|
06 | Alvaro Retana | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup |
2020-07-14
|
06 | Alvaro Retana | Ballot writeup was changed |
2020-07-14
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-07-13
|
06 | Dale Worley | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dale Worley. Sent review to list. |
2020-07-13
|
06 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2020-07-13
|
06 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-07-13
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-idr-rfc8203bis-06. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-idr-rfc8203bis-06. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the BGP Cease NOTIFICATION message subcodes subregistry in the BGP Error (Notification) Codes registry on the Border Gateway Protocol (BGP) Parameters registry page located at: https://www.iana.org/assignments/bgp-parameters/ The two existing registrations: Value: 2 Name: Administrative Shutdown Reference: [RFC4486][RFC8203] and Value: 4 Name: Administrative Reset Reference: [RFC4486][RFC8203] will have their reference changed. IANA Question --> Is [ RFC-to-be ] to be added to the existing references or is [ RFC-to-be ] to replace the existing references? The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-07-09
|
06 | Dan Romascanu | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Dan Romascanu. Sent review to list. |
2020-07-02
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2020-07-02
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2020-07-02
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2020-07-02
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2020-07-02
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2020-07-02
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2020-06-29
|
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2020-06-29
|
06 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-07-14): From: The IESG To: IETF-Announce CC: idr@ietf.org, draft-ietf-idr-rfc8203bis@ietf.org, aretana.ietf@gmail.com, shares@ndzh.com, Susan … The following Last Call announcement was sent out (ends 2020-07-14): From: The IESG To: IETF-Announce CC: idr@ietf.org, draft-ietf-idr-rfc8203bis@ietf.org, aretana.ietf@gmail.com, shares@ndzh.com, Susan Hares , idr-chairs@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Extended BGP Administrative Shutdown Communication) to Proposed Standard The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Extended BGP Administrative Shutdown Communication' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-07-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-idr-rfc8203bis/ No IPR declarations have been submitted directly on this I-D. |
2020-06-29
|
06 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2020-06-29
|
06 | Alvaro Retana | Last call was requested |
2020-06-29
|
06 | Alvaro Retana | Ballot approval text was generated |
2020-06-29
|
06 | Alvaro Retana | Ballot writeup was generated |
2020-06-29
|
06 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation |
2020-06-29
|
06 | Alvaro Retana | Last call announcement was changed |
2020-06-29
|
06 | Alvaro Retana | Last call announcement was generated |
2020-06-29
|
06 | Alvaro Retana | === AD Review of draft-ietf-idr-rfc8203bis-06 === https://mailarchive.ietf.org/arch/msg/idr/_YS4BO4UVHE502YzOmDYD_2_8HQ/ |
2020-06-26
|
06 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2020-04-16
|
06 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) Normal Shepherd's report ------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet … As required by RFC 4858, template (version: 2/24/2012) Normal Shepherd's report ------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why is this the proper type of RFC? replaces standard RFC8203 and obsoletes RFC8203. Updates RFC 4486. Is this type of RFC indicated in the title page header? yes - it indicates standard, obsoletes RFC8203, and updates RFC4486. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Support was given in IDR and grow (OPS BGP review) Document Quality Are there existing implementations of the protocol? 3 implementation of the RFC. Implementation report at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis Have a significant number of vendors indicated their plan to implement the specification? No additional implementation reports, but wide-spread operator demands so it is likely more implementations will appear. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? No MIB or Yand Doctor or other specific expert review. Personnel Document Shepherd: Susan Hares Responsible Area Director: Alvaro rRetana RTG-DIR (QA Review): Chris Hoops OPS-DIR (QA REview): Dan Romascanu (3) Briefly describe the review of this document that was performed by the Document Shepherd. 1) review of NITS 2) review of IANA section Latest comment https://mailarchive.ietf.org/arch/msg/idr/6yscvd_JEgFLK2zGPJgZcYA9GKE/ 3) review of implementations - this is correction to earlier RFC that is deployed 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.) 2. Review of document Shepherd's latest review: https://mailarchive.ietf.org/arch/msg/idr/2ooFpk69v3LNWIuDASurcaacmIk (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? RTG-DIR QA and OPS-DIR QA - indicate ready to go. Scrub 2X by authors. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Job Snijders https://mailarchive.ietf.org/arch/msg/idr/6jkJ77pl9TCuCbzgJC9OHq2hbF8 Jakob Heitz https://mailarchive.ietf.org/arch/msg/idr/J1nHk3caTh29jyHVwV9nk0dMAR4 Alexander Azimov https://mailarchive.ietf.org/arch/msg/idr/_pP_XKI00zPnDwrtC9m-tNTv-zc John Scudder https://mailarchive.ietf.org/arch/msg/idr/5tqVhN_aupX8iG0UVpd4P3pjE0E Notice about requiring John Scudder https://mailarchive.ietf.org/arch/msg/idr/guP5ElRltCFxkpueA0XFbPays_s (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None Nits comments below -- but this was chased multiple times and the authors gave permissions. See comments on mail list: https://mailarchive.ietf.org/arch/msg/idr/rhoFMTXcHeCiUEPEVPhex_M48Eg/ RFC5378 checks: 2006-01-25) -- 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.) -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with ' ' and |
2020-04-16
|
06 | Susan Hares | Responsible AD changed to Alvaro Retana |
2020-04-16
|
06 | Susan Hares | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-04-16
|
06 | Susan Hares | IESG state changed to Publication Requested from I-D Exists |
2020-04-16
|
06 | Susan Hares | IESG process started in state Publication Requested |
2020-04-16
|
06 | Susan Hares | Tags Other - see Comment Log, Revised I-D Needed - Issue raised by WG cleared. |
2020-04-16
|
06 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) Normal Shepherd's report ------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet … As required by RFC 4858, template (version: 2/24/2012) Normal Shepherd's report ------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why is this the proper type of RFC? replaces standard RFC8203 and obsoletes RFC8203. Updates RFC 4486. Is this type of RFC indicated in the title page header? yes - it indicates standard, obsoletes RFC8203, and updates RFC4486. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Support was given in IDR and grow (OPS BGP review) Document Quality Are there existing implementations of the protocol? 3 implementation of the RFC. Implementation report at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis Have a significant number of vendors indicated their plan to implement the specification? No additional implementation reports, but wide-spread operator demands so it is likely more implementations will appear. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? No MIB or Yand Doctor or other specific expert review. Personnel Document Shepherd: Susan Hares Responsible Area Director: Alvaro rRetana RTG-DIR (QA Review): Chris Hoops OPS-DIR (QA REview): Dan Romascanu (3) Briefly describe the review of this document that was performed by the Document Shepherd. 1) review of NITS 2) review of IANA section Latest comment https://mailarchive.ietf.org/arch/msg/idr/6yscvd_JEgFLK2zGPJgZcYA9GKE/ 3) review of implementations - this is correction to earlier RFC that is deployed 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.) 2. Review of document Shepherd's latest review: https://mailarchive.ietf.org/arch/msg/idr/2ooFpk69v3LNWIuDASurcaacmIk (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? RTG-DIR QA and OPS-DIR QA - indicate ready to go. Scrub 2X by authors. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Job Snijders https://mailarchive.ietf.org/arch/msg/idr/6jkJ77pl9TCuCbzgJC9OHq2hbF8 Jakob Heitz https://mailarchive.ietf.org/arch/msg/idr/J1nHk3caTh29jyHVwV9nk0dMAR4 Alexander Azimov https://mailarchive.ietf.org/arch/msg/idr/_pP_XKI00zPnDwrtC9m-tNTv-zc John Scudder https://mailarchive.ietf.org/arch/msg/idr/5tqVhN_aupX8iG0UVpd4P3pjE0E Notice about requiring John Scudder https://mailarchive.ietf.org/arch/msg/idr/guP5ElRltCFxkpueA0XFbPays_s (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None Nits comments below -- but this was chased multiple times and the authors gave permissions. See comments on mail list: https://mailarchive.ietf.org/arch/msg/idr/rhoFMTXcHeCiUEPEVPhex_M48Eg/ RFC5378 checks: 2006-01-25) -- 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.) -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with ' ' and |
2020-04-16
|
06 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) Normal Shepherd's report ------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet … As required by RFC 4858, template (version: 2/24/2012) Normal Shepherd's report ------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why is this the proper type of RFC? replaces standard RFC8203 and obsoletes RFC8203. Updates RFC 4486. Is this type of RFC indicated in the title page header? yes - it indicates standard, obsoletes RFC8203, and updates RFC4486. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Support was given in IDR and grow (OPS BGP review) Document Quality Are there existing implementations of the protocol? 3 implementation of the RFC. Implementation report at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis Have a significant number of vendors indicated their plan to implement the specification? No additional implementation reports, but wide-spread operator demands so it is likely more implementations will appear. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? No MIB or Yand Doctor or other specific expert review. Personnel Document Shepherd: Susan Hares Responsible Area Director: Alvaro rRetana RTG-DIR (QA Review): Chris Hoops OPS-DIR (QA REview): Dan Romascanu (3) Briefly describe the review of this document that was performed by the Document Shepherd. 1) review of NITS 2) review of IANA section 3) review of implementations - this is correction to earlier RFC that is deployed 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.) 2. Review of document Shepherd's latest review: https://mailarchive.ietf.org/arch/msg/idr/2ooFpk69v3LNWIuDASurcaacmIk (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? RTG-DIR QA and OPS-DIR QA - indicate ready to go. Scrub 2X by authors. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Job Snijders https://mailarchive.ietf.org/arch/msg/idr/6jkJ77pl9TCuCbzgJC9OHq2hbF8 Jakob Heitz https://mailarchive.ietf.org/arch/msg/idr/J1nHk3caTh29jyHVwV9nk0dMAR4 Alexander Azimov https://mailarchive.ietf.org/arch/msg/idr/_pP_XKI00zPnDwrtC9m-tNTv-zc John Scudder https://mailarchive.ietf.org/arch/msg/idr/5tqVhN_aupX8iG0UVpd4P3pjE0E Notice about requiring John Scudder https://mailarchive.ietf.org/arch/msg/idr/guP5ElRltCFxkpueA0XFbPays_s (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None Nits comments below -- but this was chased multiple times and the authors gave permissions. RFC5378 checks: 2006-01-25) -- 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.) -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with ' ' and |
2020-04-15
|
06 | John Scudder | New version available: draft-ietf-idr-rfc8203bis-06.txt |
2020-04-15
|
06 | (System) | New version accepted (logged-in submitter: John Scudder) |
2020-04-15
|
06 | John Scudder | Uploaded new revision |
2020-03-03
|
05 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) Status: Need IANA section changed, and Implementation report on BIRD fixed. Required change in document (nit … As required by RFC 4858, template (version: 2/24/2012) Status: Need IANA section changed, and Implementation report on BIRD fixed. Required change in document (nit level) IN section: 5. IANA Considerations Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Normal Shepherd's report ------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why is this the proper type of RFC? replaces standard RFC8203 and obsoletes RFC8203. Updates RFC 4486. Is this type of RFC indicated in the title page header? yes - it indicates standard, obsoletes RFC8203, and updates RFC4486. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Support was given in IDR and grow (OPS BGP review) Document Quality Are there existing implementations of the protocol? 3 implementation of the RFC. Implementation report at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis Have a significant number of vendors indicated their plan to implement the specification? No additional implementation reports, but wide-spread operator demands so it is likely more implementations will appear. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? No MIB or Yand Doctor or other specific expert review. Personnel Document Shepherd: Susan Hares Responsible Area Director: Alvaro rRetana RTG-DIR (QA Review): Chris Hoops OPS-DIR (QA REview): Dan Romascanu (3) Briefly describe the review of this document that was performed by the Document Shepherd. Shepherd review references: #1 - Pre-WG LC shepherd report https://mailarchive.ietf.org/arch/msg/idr/rhoFMTXcHeCiUEPEVPhex_M48Eg 1. Nits: found: update RFC4486 (pre-RFC5378) work so BCP78 disclaimer needed However the BCP78 rights were granted with RFC8203. This was confirmed by retrieving this email. [Thanks to John Scudder for recalling this as the RFC8203 shepherd] -- 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.) 2. Review of document Shepherd's latest review: https://mailarchive.ietf.org/arch/msg/idr/2ooFpk69v3LNWIuDASurcaacmIk Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Why: registry name at: https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-8 is the contained in new test 2. check of implementation reports: Please fix (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? RTG-DIR QA and OPS-DIR QA - indicate ready to go. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Job Snijders https://mailarchive.ietf.org/arch/msg/idr/6jkJ77pl9TCuCbzgJC9OHq2hbF8 Jakob Heitz https://mailarchive.ietf.org/arch/msg/idr/J1nHk3caTh29jyHVwV9nk0dMAR4 Alexander Azimov https://mailarchive.ietf.org/arch/msg/idr/_pP_XKI00zPnDwrtC9m-tNTv-zc John Scudder https://mailarchive.ietf.org/arch/msg/idr/5tqVhN_aupX8iG0UVpd4P3pjE0E Notice about requiring John Scudder https://mailarchive.ietf.org/arch/msg/idr/guP5ElRltCFxkpueA0XFbPays_s (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus with strong operator support (Grow). (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) no (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No - boiler plate check already [see discussion with Alvaro Retana ] (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional document reviews beyond OPS-DIR and RTG-DIR. (13) Have all references within this document been identified as either normative or informative? yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? obsoletes RFC 8203 (as replacement) updates RFC4486 (as addition) RFCS are listed on title page, the abstract, and introduction. Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? yes If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No - just update to (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. IANA is requested to reference this document at subcode "Administrative Shutdown", and at subcode "Administrative Reset" in the "Cease NOTIFICATION message subcodes" registry under the "Border Gateway Protocol (BGP) Parameters" group in addition to [RFC4486] and [RFC8203]. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. no automated checks needed. |
2019-10-25
|
05 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) Status: Need IANA section changed, and Implementation report on BIRD fixed. Required change in document (nit … As required by RFC 4858, template (version: 2/24/2012) Status: Need IANA section changed, and Implementation report on BIRD fixed. Required change in document (nit level) IN section: 5. IANA Considerations Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Normal Shepherd's report ------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why is this the proper type of RFC? replaces standard RFC8203 and obsoletes RFC8203. Updates RFC 4486. Is this type of RFC indicated in the title page header? yes - it indicates standard, obsoletes RFC8203, and updates RFC4486. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Support was given in IDR and grow (OPS BGP review) Document Quality Are there existing implementations of the protocol? 3 implementation of the RFC. Implementation report at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis Have a significant number of vendors indicated their plan to implement the specification? No additional implementation reports, but wide-spread operator demands so it is likely more implementations will appear. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? No MIB or Yand Doctor or other specific expert review. Personnel Document Shepherd: Susan Hares Responsible Area Director: Alvaro rRetana RTG-DIR (QA Review): Chris Hoops OPS-DIR (QA REview): Dan Romascanu (3) Briefly describe the review of this document that was performed by the Document Shepherd. Shepherd review references: #1 - Pre-WG LC shepherd report https://mailarchive.ietf.org/arch/msg/idr/rhoFMTXcHeCiUEPEVPhex_M48Eg 1. Nits: found: update RFC4486 (pre-RFC5378) work so BCP78 disclaimer needed However the BCP78 rights were granted with RFC8203. This was confirmed by retrieving this email. [Thanks to John Scudder for recalling this as the RFC8203 shepherd] -- 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.) 2. Review of document Shepherd's latest review: https://mailarchive.ietf.org/arch/msg/idr/2ooFpk69v3LNWIuDASurcaacmIk Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Why: registry name at: https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-8 is the contained in new test 2. check of implementation reports: Please fix (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? RTG-DIR QA and OPS-DIR QA - indicate ready to go. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Job Snijders https://mailarchive.ietf.org/arch/msg/idr/6jkJ77pl9TCuCbzgJC9OHq2hbF8 Jakob Heitz https://mailarchive.ietf.org/arch/msg/idr/J1nHk3caTh29jyHVwV9nk0dMAR4 Alexander Azimov https://mailarchive.ietf.org/arch/msg/idr/_pP_XKI00zPnDwrtC9m-tNTv-zc John Scudder https://mailarchive.ietf.org/arch/msg/idr/5tqVhN_aupX8iG0UVpd4P3pjE0E Notice about requiring John Scudder https://mailarchive.ietf.org/arch/msg/idr/guP5ElRltCFxkpueA0XFbPays_s (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus with strong operator support (Grow). (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) no (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No - boiler plate check already [see discussion with Alvaro Retana ] (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional document reviews beyond OPS-DIR and RTG-DIR. (13) Have all references within this document been identified as either normative or informative? yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? obsoletes RFC 8203 (as replacement) updates RFC4486 (as addition) RFCS are listed on title page, the abstract, and introduction. Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? yes If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No - just update to (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. IANA is requested to reference this document at subcode "Administrative Shutdown", and at subcode "Administrative Reset" in the "Cease NOTIFICATION message subcodes" registry under the "Border Gateway Protocol (BGP) Parameters" group in addition to [RFC4486] and [RFC8203]. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. no automated checks needed. |
2019-10-18
|
05 | Gunter Van de Velde | Assignment of request for Early review by OPSDIR to Tina Tsou was marked no-response |
2019-10-16
|
05 | John Scudder | New version available: draft-ietf-idr-rfc8203bis-05.txt |
2019-10-16
|
05 | (System) | New version accepted (logged-in submitter: John Scudder) |
2019-10-16
|
05 | John Scudder | Uploaded new revision |
2019-10-01
|
04 | Dan Romascanu | Request for Early review by OPSDIR Completed: Has Issues. Reviewer: Dan Romascanu. Sent review to list. |
2019-09-26
|
04 | Min Ye | Closed request for Early review by RTGDIR with state 'Withdrawn' |
2019-09-26
|
04 | Min Ye | Assignment of request for Early review by RTGDIR to Eric Gray was withdrawn |
2019-09-25
|
04 | Christian Hopps | Request for Early review by RTGDIR Completed: Ready. Reviewer: Christian Hopps. Sent review to list. |
2019-09-19
|
04 | Carlos Pignataro | Assignment of request for Early review by OPSDIR to Carlos Pignataro was rejected |
2019-09-19
|
04 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Tina Tsou |
2019-09-19
|
04 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Tina Tsou |
2019-09-19
|
04 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Dan Romascanu |
2019-09-19
|
04 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Dan Romascanu |
2019-09-19
|
04 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Carlos Pignataro |
2019-09-19
|
04 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Carlos Pignataro |
2019-09-17
|
04 | Min Ye | Request for Early review by RTGDIR is assigned to Christian Hopps |
2019-09-17
|
04 | Min Ye | Request for Early review by RTGDIR is assigned to Christian Hopps |
2019-09-15
|
04 | Min Ye | Closed request for Early review by RTGDIR with state 'Withdrawn' |
2019-09-12
|
04 | Luc André Burdet | Request for Early review by RTGDIR is assigned to Eric Gray |
2019-09-12
|
04 | Luc André Burdet | Request for Early review by RTGDIR is assigned to Eric Gray |
2019-09-12
|
04 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) Status: 1) waiting for early reviews: RTG-DIR QA review, and OPS-DIR QA Review. … As required by RFC 4858, template (version: 2/24/2012) Status: 1) waiting for early reviews: RTG-DIR QA review, and OPS-DIR QA Review. 2) waiting for updates to implemntation report for OpenBSD and BIRD 3) Waiting on -05 with changes below Required change in document: In introduction: Add to end of paragraph 1: /This draft obsoletes RFC8203./ IN section: 5. IANA Considerations Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Normal Shepherd's report ------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why is this the proper type of RFC? replaces standard RFC8203 and obsoletes RFC8203. Updates RFC 4486. Is this type of RFC indicated in the title page header? yes - it indicates standard, obsoletes RFC8203, and updates RFC4486. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Support was given in IDR and grow (OPS BGP review) Document Quality Are there existing implementations of the protocol? 3 implementation of the RFC. Implementation report at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis Have a significant number of vendors indicated their plan to implement the specification? No additional implementation reports, but wide-spread operator demands so it is likely more implementations will appear. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? No MIB or Yand Doctor or other specific expert review. [TBD] RTG-DIR early review [TBD] OPS-DIR early review Personnel Document Shepherd: Susan Hares Responsible Area Director: Alvaro rRetana RTG-DIR (QA Review): TBD OPS-DIR (QA REview): TBD (3) Briefly describe the review of this document that was performed by the Document Shepherd. Shepherd review references: #1 - Pre-WG LC shepherd report https://mailarchive.ietf.org/arch/msg/idr/rhoFMTXcHeCiUEPEVPhex_M48Eg 1. Nits: found: update RFC4486 (pre-RFC5378) work so BCP78 disclaimer needed However the BCP78 rights were granted with RFC8203. This was confirmed by retrieving this email. [Thanks to John Scudder for recalling this as the RFC8203 shepherd] -- 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.) 2. Review of document Shepherd's latest review: https://mailarchive.ietf.org/arch/msg/idr/NOfNx_WYnbOmGE0pAMf6-hrzLtw Shepherd's Required text changes: a) IANA Considerations IN section: 5. IANA Considerations Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Why: registry name at: https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-8 is the contained in new test 2. check of implementation reports Unclear how OpenBSD and BIRD fill in the implementation document. Authors must change 3. NITS on the BCP78 rights for RFCRFC4486 are incorrect. These rights have already been granted to the IETF in RFC8203. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? RTG-DIR QA and OPS-DIR QA should be done. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Job Snijders https://mailarchive.ietf.org/arch/msg/idr/6jkJ77pl9TCuCbzgJC9OHq2hbF8 Jakob Heitz https://mailarchive.ietf.org/arch/msg/idr/J1nHk3caTh29jyHVwV9nk0dMAR4 Alexander Azimov https://mailarchive.ietf.org/arch/msg/idr/_pP_XKI00zPnDwrtC9m-tNTv-zc John Scudder https://mailarchive.ietf.org/arch/msg/idr/5tqVhN_aupX8iG0UVpd4P3pjE0E Notice about requiring John Scudder https://mailarchive.ietf.org/arch/msg/idr/guP5ElRltCFxkpueA0XFbPays_s (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus with strong operator support (Grow). (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) no (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 1. Nits: found an in correct request for BCP78 rights for RFCRFC4486. Rights have already been granted with RFC8203. -- 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.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional document reviews beyond OPS-DIR and RTG-DIR. (13) Have all references within this document been identified as either normative or informative? yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? obsoletes RFC 8203 (as replacement) updates RFC4486 (as addition) RFCS are listed on title page, the abstract, and introduction. [TBD: RFC8203 must be mentioned in the introduction] Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? [-05] required for RFC8203 obsoletion in introduction. If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). [TBD] fill in after check (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. no automated checks needed. |
2019-09-11
|
04 | Susan Hares | Requested Early review by RTGDIR |
2019-09-11
|
04 | Susan Hares | Requested Early review by OPSDIR |
2019-09-11
|
04 | Susan Hares | Requested Early review by RTGDIR |
2019-09-11
|
04 | Susan Hares | Requested Early review by OPSDIR |
2019-09-11
|
04 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) Status: 1) requested RTG-DIR QA review, and OPS-DIR QA Review. … As required by RFC 4858, template (version: 2/24/2012) Status: 1) requested RTG-DIR QA review, and OPS-DIR QA Review. 2) Asking Alvaro's comment on NITS issue 3) Will not pass until editorial change in section 5 Required change in document: IN section: 5. IANA Considerations Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Normal Shepherd's report ------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why is this the proper type of RFC? replaces standard RFC8203 and obsoletes RFC8203. Updates RFC 4486. Is this type of RFC indicated in the title page header? yes - it indicates standard, obsoletes RFC8203, and updates RFC4486. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Support was given in IDR and grow (OPS BGP review) Document Quality Are there existing implementations of the protocol? 3 implementation of the RFC. Implementation report at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis Have a significant number of vendors indicated their plan to implement the specification? No additional implementation reports, but wide-spread operator demands so it is likely more implementations will appear. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? No MIB or Yand Doctor or other specific expert review. [TBD] RTG-DIR early review [TBD] OPS-DIR early review Personnel Document Shepherd: Susan Hares Responsible Area Director: Alvaro rRetana RTG-DIR (QA Review): TBD OPS-DIR (QA REview): TBD (3) Briefly describe the review of this document that was performed by the Document Shepherd. Shepherd review references: #1 - Pre-WG LC shepherd report https://mailarchive.ietf.org/arch/msg/idr/rhoFMTXcHeCiUEPEVPhex_M48Eg 1. Nits: found: update RFC4486 (pre-RFC5378) work so BCP78 disclaimer needed (see below) (TBD: Asked for Alvaro's guidance) -- 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.) 2. Review of document Shepherd's Required Changes: 2.1) above nits needs to be resolved 2.3) IANA Considerations IN section: 5. IANA Considerations Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Why: registry name at: https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-8 is the contained in new test 3. check of implementation reports Unclear how OpenBSD and BIRD fill in the imoplementation document. Authors must change ---- If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. [leave question until IESG send] (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? RTG-DIR QA and OPS-DIR QA should be done. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Job Snijders https://mailarchive.ietf.org/arch/msg/idr/6jkJ77pl9TCuCbzgJC9OHq2hbF8 Jakob Heitz https://mailarchive.ietf.org/arch/msg/idr/J1nHk3caTh29jyHVwV9nk0dMAR4 Alexander Azimov https://mailarchive.ietf.org/arch/msg/idr/_pP_XKI00zPnDwrtC9m-tNTv-zc John Scudder https://mailarchive.ietf.org/arch/msg/idr/5tqVhN_aupX8iG0UVpd4P3pjE0E Notice about requiring John Scudder https://mailarchive.ietf.org/arch/msg/idr/guP5ElRltCFxkpueA0XFbPays_s (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? [tbd] (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) [TBD] (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 1. Nits: 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.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional document reviews beyond OPS-DIR and RTG-DIR. (13) Have all references within this document been identified as either normative or informative? yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? obsoletes RFC 8203 (as replacement) updates RFC4486 (as addition) RFCS are listed on title page, the abstract, and introduction. [TBD: RFC8203 must be mentioned in the introduction] Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? [TBD] If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). [TBD] fill in after check (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. no automated checks needed. |
2019-09-11
|
04 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) Status: 1) requested RTG-DIR QA review, and OPS-DIR QA Review. … As required by RFC 4858, template (version: 2/24/2012) Status: 1) requested RTG-DIR QA review, and OPS-DIR QA Review. 2) Asking Alvaro's comment on NITS issue 3) Will not pass until editorial change in section 5 Required change in document: IN section: 5. IANA Considerations Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Normal Shepherd's report ------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why is this the proper type of RFC? replaces standard RFC8203 and obsoletes RFC8203. Updates RFC 4486. Is this type of RFC indicated in the title page header? yes - it indicates standard, obsoletes RFC8203, and updates RFC4486. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Support was given in IDR and grow (OPS BGP review) Document Quality Are there existing implementations of the protocol? 3 implementation of the RFC. Implementation report at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis Have a significant number of vendors indicated their plan to implement the specification? No additional implementation reports, but wide-spread operator demands so it is likely more implementations will appear. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? No MIB or Yand Doctor or other specific expert review. [TBD] RTG-DIR early review [TBD] OPS-DIR early review Personnel Document Shepherd: Susan Hares Responsible Area Director: Alvaro rRetana RTG-DIR (QA Review): TBD OPS-DIR (QA REview): TBD (3) Briefly describe the review of this document that was performed by the Document Shepherd. Shepherd review references: #1 - Pre-WG LC shepherd report https://mailarchive.ietf.org/arch/msg/idr/rhoFMTXcHeCiUEPEVPhex_M48Eg 1. Nits: found: update RFC4486 (pre-RFC5378) work so BCP78 disclaimer needed (see below) (TBD: Asked for Alvaro's guidance) -- 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.) 2. Review of document Shepherd's Required Changes: 2.1) above nits needs to be resolved 2.3) IANA Considerations IN section: 5. IANA Considerations Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Why: registry name at: https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-8 is the contained in new test 3. check of implementation reports Unclear how OpenBSD and BIRD fill in the imoplementation document. Authors must change ---- If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. [leave question until IESG send] (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? RTG-DIR QA and OPS-DIR QA should be done. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Job Snijders https://mailarchive.ietf.org/arch/msg/idr/6jkJ77pl9TCuCbzgJC9OHq2hbF8 Jakob Heitz https://mailarchive.ietf.org/arch/msg/idr/J1nHk3caTh29jyHVwV9nk0dMAR4 Alexander Azimov https://mailarchive.ietf.org/arch/msg/idr/_pP_XKI00zPnDwrtC9m-tNTv-zc John Scudder https://mailarchive.ietf.org/arch/msg/idr/5tqVhN_aupX8iG0UVpd4P3pjE0E Notice about requiring John Scudder https://mailarchive.ietf.org/arch/msg/idr/guP5ElRltCFxkpueA0XFbPays_s (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? [tbd] (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) [TBD] (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 1. Nits: 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.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional document reviews beyond OPS-DIR and RTG-DIR. (13) Have all references within this document been identified as either normative or informative? yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? obsoletes RFC 8203 (as replacement) updates RFC4486 (as addition) RFCS are listed on title page, the abstract, and introduction. [TBD: RFC8203 must be mentioned in the introduction] Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? [TBD] If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). [TBD] fill in after check (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. no automated checks needed. |
2019-09-11
|
04 | Susan Hares | Requested Early review by RTGDIR |
2019-09-11
|
04 | Susan Hares | Requested Early review by OPSDIR |
2019-08-07
|
04 | Susan Hares | After revision 4 is posted, the implementation page may need to be updated. The shepherd will begin working on the write-up. |
2019-08-07
|
04 | Susan Hares | Tag Revised I-D Needed - Issue raised by WG set. |
2019-08-07
|
04 | Susan Hares | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2019-07-09
|
04 | Susan Hares | IPR issue outstanding due to boiler plate. |
2019-07-09
|
04 | Susan Hares | Tag Other - see Comment Log set. |
2019-07-09
|
04 | Susan Hares | IETF WG state changed to In WG Last Call from WG Document |
2019-06-10
|
04 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) date: 6/7/2017 Status: Awaiting version-05 before send to RTG-DIR QA review, and OPS-DIR QA Review. WG … As required by RFC 4858, template (version: 2/24/2012) date: 6/7/2017 Status: Awaiting version-05 before send to RTG-DIR QA review, and OPS-DIR QA Review. WG LC Status: Awaiting version -05 and Scudder IPR before starting WG LC (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why is this the proper type of RFC? replaces standard RFC8203 and obsoletes RFC8203. Updates RFC 4486. Is this type of RFC indicated in the title page header? yes - it indicates standard, obsoletes RFC8203, and updates RFC4486. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? [TBD after WG LC ] Document Quality Are there existing implementations of the protocol? 3 implementation of the RFC. Implementation report at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis Have a significant number of vendors indicated their plan to implement the specification? No additional implementation reports, but wide-spread operator demands so it is likely more implementations will appear. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? No MIB or Yand Doctor or other specific expert review. [TBD] RTG-DIR review. Personnel Document Shepherd: Susan Hares Responsible Area Director: Alvaro rRetana RTG-DIR (QA Review): TBD OPS-DIR (QA REview): TBD (3) Briefly describe the review of this document that was performed by the Document Shepherd. Shepherd review references: #1 - Pre-WG LC shepherd report https://mailarchive.ietf.org/arch/msg/idr/rhoFMTXcHeCiUEPEVPhex_M48Eg 1. Nits: 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.) 2. Review of document Required Changes: 2.1) above nits needs to be resolved 2.2) RFC8203 must be mentioned in the introduction as well as current references (top of front page, Abstract) 2.3) IANA Considerations IN section: 5. IANA Considerations Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Why: registry name at: https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-8 is the contained in new test 3. check of implementation reports Unclear how OpenBSD and BIRD fill in the imoplementation document. Authors must change ---- If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. [leave question until IESG send] (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? RTG-DIR QA and OPS-DIR QA should be done. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Job Snijders https://mailarchive.ietf.org/arch/msg/idr/6jkJ77pl9TCuCbzgJC9OHq2hbF8 Jakob Heitz https://mailarchive.ietf.org/arch/msg/idr/J1nHk3caTh29jyHVwV9nk0dMAR4 Alexander Azimov https://mailarchive.ietf.org/arch/msg/idr/_pP_XKI00zPnDwrtC9m-tNTv-zc John Scudder https://mailarchive.ietf.org/arch/msg/idr/5tqVhN_aupX8iG0UVpd4P3pjE0E Notice about requiring John Scudder https://mailarchive.ietf.org/arch/msg/idr/guP5ElRltCFxkpueA0XFbPays_s (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? [tbd] (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) [TBD] (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 1. Nits: 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.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional document reviews beyond OPS-DIR and RTG-DIR. (13) Have all references within this document been identified as either normative or informative? yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? obsoletes RFC 8203 (as replacement) updates RFC4486 (as addition) RFCS are listed on title page, the abstract, and introduction. [TBD: RFC8203 must be mentioned in the introduction] Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? [TBD] If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). [TBD] fill in after check (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. no automated checks needed. |
2019-06-07
|
04 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) date: 6/7/2017 Status: Awaiting version-05 before send to RTG-DIR QA review, and OPS-DIR QA Review. IPR … As required by RFC 4858, template (version: 2/24/2012) date: 6/7/2017 Status: Awaiting version-05 before send to RTG-DIR QA review, and OPS-DIR QA Review. IPR Status: Awaiting John Scudder IPR WG LC Status: Awaiting version -05 and Scudder IPR before starting WG LC (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why is this the proper type of RFC? replaces standard RFC8203 and obsoletes RFC8203. Updates RFC 4486. Is this type of RFC indicated in the title page header? yes - it indicates standard, obsoletes RFC8203, and updates RFC4486. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? [TBD after WG LC ] Document Quality Are there existing implementations of the protocol? 3 implementation of the RFC. Implementation report at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis Have a significant number of vendors indicated their plan to implement the specification? No additional implementation reports, but wide-spread operator demands so it is likely more implementations will appear. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? No MIB or Yand Doctor or other specific expert review. [TBD] RTG-DIR review. Personnel Document Shepherd: Susan Hares Responsible Area Director: Alvaro rRetana RTG-DIR (QA Review): TBD OPS-DIR (QA REview): TBD (3) Briefly describe the review of this document that was performed by the Document Shepherd. Shepherd review references: #1 - Pre-WG LC shepherd report https://mailarchive.ietf.org/arch/msg/idr/rhoFMTXcHeCiUEPEVPhex_M48Eg 1. Nits: 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.) 2. Review of document Required Changes: 2.1) above nits needs to be resolved 2.2) RFC8203 must be mentioned in the introduction as well as current references (top of front page, Abstract) 2.3) IANA Considerations IN section: 5. IANA Considerations Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Why: registry name at: https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-8 is the contained in new test 3. check of implementation reports Unclear how OpenBSD and BIRD fill in the imoplementation document. Authors must change ---- If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. [leave question until IESG send] (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? RTG-DIR QA and OPS-DIR QA should be done. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Job Snijders https://mailarchive.ietf.org/arch/msg/idr/6jkJ77pl9TCuCbzgJC9OHq2hbF8 Jakob Heitz https://mailarchive.ietf.org/arch/msg/idr/J1nHk3caTh29jyHVwV9nk0dMAR4 Alexander Azimov https://mailarchive.ietf.org/arch/msg/idr/_pP_XKI00zPnDwrtC9m-tNTv-zc John Scudder [TBD] Notice about requiring John Scudder https://mailarchive.ietf.org/arch/msg/idr/guP5ElRltCFxkpueA0XFbPays_s (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? [tbd] (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) [TBD] (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 1. Nits: 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.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional document reviews beyond OPS-DIR and RTG-DIR. (13) Have all references within this document been identified as either normative or informative? yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? obsoletes RFC 8203 (as replacement) updates RFC4486 (as addition) RFCS are listed on title page, the abstract, and introduction. [TBD: RFC8203 must be mentioned in the introduction] Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? [TBD] If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). [TBD] fill in after check (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. no automated checks needed. |
2019-06-07
|
04 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) date: 6/7/2017 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, … As required by RFC 4858, template (version: 2/24/2012) date: 6/7/2017 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why is this the proper type of RFC? replaces standard RFC8203 and obsoletes RFC8203. Updates RFC 4486. Is this type of RFC indicated in the title page header? yes - it indicates standard, obsoletes RFC8203, and updates RFC4486. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? [TBD after WG LC ] Document Quality Are there existing implementations of the protocol? 3 implementation of the RFC. Implementation report at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis Have a significant number of vendors indicated their plan to implement the specification? No additional implementation reports, but wide-spread operator demands so it is likely more implementations will appear. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? No MIB or Yand Doctor or other specific expert review. [TBD] RTG-DIR review. Personnel Document Shepherd: Susan Hares Responsible Area Director: Alvaro rRetana RTG-DIR (QA Review): TBD OPS-DIR (QA REview): TBD (3) Briefly describe the review of this document that was performed by the Document Shepherd. Shepherd review references: #1 - Pre-WG LC shepherd report https://mailarchive.ietf.org/arch/msg/idr/rhoFMTXcHeCiUEPEVPhex_M48Eg 1. Nits: 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.) 2. Review of document Required Changes: 2.1) above nits needs to be resolved 2.2) RFC8203 must be mentioned in the introduction as well as current references (top of front page, Abstract) 2.3) IANA Considerations IN section: 5. IANA Considerations Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Why: registry name at: https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-8 is the contained in new test 3. check of implementation reports Unclear how OpenBSD and BIRD fill in the imoplementation document. Authors must change ---- If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. [leave question until IESG send] (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? RTG-DIR QA and OPS-DIR QA should be done. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Job Snijders https://mailarchive.ietf.org/arch/msg/idr/6jkJ77pl9TCuCbzgJC9OHq2hbF8 Jakob Heitz https://mailarchive.ietf.org/arch/msg/idr/J1nHk3caTh29jyHVwV9nk0dMAR4 Alexander Azimov https://mailarchive.ietf.org/arch/msg/idr/_pP_XKI00zPnDwrtC9m-tNTv-zc John Scudder [TBD] Notice about requiring John Scudder https://mailarchive.ietf.org/arch/msg/idr/guP5ElRltCFxkpueA0XFbPays_s (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? [tbd] (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) [TBD] (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 1. Nits: 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.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional document reviews beyond OPS-DIR and RTG-DIR. (13) Have all references within this document been identified as either normative or informative? yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? obsoletes RFC 8203 (as replacement) updates RFC4486 (as addition) RFCS are listed on title page, the abstract, and introduction. [TBD: RFC8203 must be mentioned in the introduction] Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? [TBD] If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). [TBD] fill in after check (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. no automated checks needed. |
2019-06-07
|
04 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) date: 6/7/2017 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, … As required by RFC 4858, template (version: 2/24/2012) date: 6/7/2017 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why is this the proper type of RFC? replaces standard RFC8203 and obsoletes RFC8203. Updates RFC 4486. Is this type of RFC indicated in the title page header? yes - it indicates standard, obsoletes RFC8203, and updates RFC4486. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? [TBD after WG LC ] Document Quality Are there existing implementations of the protocol? 3 implementation of the RFC. Implementation report at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis Have a significant number of vendors indicated their plan to implement the specification? No additional implementation reports, but wide-spread operator demands so it is likely more implementations will appear. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? No MIB or Yand Doctor or other specific expert review. [TBD] RTG-DIR review. Personnel Document Shepherd: Susan Hares Responsible Area Director: Alvaro rRetana RTG-DIR (QA Review): TBD OPS-DIR (QA REview): TBD (3) Briefly describe the review of this document that was performed by the Document Shepherd. 1. Nits: 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.) 2. Review of document Required Changes: 2.1) above nits needs to be resolved 2.2) RFC8203 must be mentioned in the introduction as well as current references (top of front page, Abstract) 2.3) IANA Considerations IN section: 5. IANA Considerations Old: /Cease Notification message subcodes/ New: /BGP Cease NOTIFICATION message subcodes/ Why: registry name at: https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-8 is the contained in new test 3. check of implementation reports Unclear how OpenBSD and BIRD fill in the imoplementation document. Authors must change ---- If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. [leave question until IESG send] (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? RTG-DIR QA and OPS-DIR QA should be done. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Job Snijders https://mailarchive.ietf.org/arch/msg/idr/6jkJ77pl9TCuCbzgJC9OHq2hbF8 Jakob Heitz https://mailarchive.ietf.org/arch/msg/idr/J1nHk3caTh29jyHVwV9nk0dMAR4 Alexander Azimov https://mailarchive.ietf.org/arch/msg/idr/_pP_XKI00zPnDwrtC9m-tNTv-zc John Scudder [TBD] Notice about requiring John Scudder https://mailarchive.ietf.org/arch/msg/idr/guP5ElRltCFxkpueA0XFbPays_s (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? [tbd] (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) [TBD] (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 1. Nits: 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.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional document reviews beyond OPS-DIR and RTG-DIR. (13) Have all references within this document been identified as either normative or informative? yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? obsoletes RFC 8203 (as replacement) updates RFC4486 (as addition) RFCS are listed on title page, the abstract, and introduction. [TBD: RFC8203 must be mentioned in the introduction] Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? [TBD] If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). [TBD] fill in after check (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. no automated checks needed. |
2019-06-07
|
04 | Susan Hares | As required by RFC 4858, template (version: 2/24/2012) (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or … As required by RFC 4858, template (version: 2/24/2012) (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director? (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. |
2019-06-07
|
04 | Susan Hares | Changed consensus to Yes from Unknown |
2019-06-07
|
04 | Susan Hares | Intended Status changed to Proposed Standard from None |
2019-06-07
|
04 | Susan Hares | Notification list changed to Susan Hares <shares@ndzh.com> |
2019-06-07
|
04 | Susan Hares | Document shepherd changed to Susan Hares |
2019-06-07
|
04 | Susan Hares | Notification list changed to Susan Hares <shares@ndzh.com> |
2019-06-07
|
04 | Susan Hares | Document shepherd changed to Susan Hares |
2019-04-29
|
04 | Job Snijders | New version available: draft-ietf-idr-rfc8203bis-04.txt |
2019-04-29
|
04 | (System) | New version approved |
2019-04-29
|
04 | (System) | Request for posting confirmation emailed to previous authors: Job Snijders , Jakob Heitz , Alexander Azimov , John Scudder |
2019-04-29
|
04 | Job Snijders | Uploaded new revision |
2019-04-25
|
03 | Job Snijders | New version available: draft-ietf-idr-rfc8203bis-03.txt |
2019-04-25
|
03 | (System) | New version approved |
2019-04-25
|
03 | (System) | Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, Alexander Azimov , Jakob Heitz , Job Snijders , John Scudder |
2019-04-25
|
03 | Job Snijders | Uploaded new revision |
2019-04-25
|
02 | Job Snijders | New version available: draft-ietf-idr-rfc8203bis-02.txt |
2019-04-25
|
02 | (System) | New version approved |
2019-04-25
|
02 | (System) | Request for posting confirmation emailed to previous authors: Job Snijders , Alexander Azimov , Jakob Heitz , John Scudder |
2019-04-25
|
02 | Job Snijders | Uploaded new revision |
2019-04-25
|
01 | (System) | Document has expired |
2018-10-22
|
01 | Job Snijders | New version available: draft-ietf-idr-rfc8203bis-01.txt |
2018-10-22
|
01 | (System) | New version approved |
2018-10-22
|
01 | (System) | Request for posting confirmation emailed to previous authors: Job Snijders , Alexander Azimov , Jakob Heitz , John Scudder |
2018-10-22
|
01 | Job Snijders | Uploaded new revision |
2018-04-30
|
00 | John Scudder | This document now replaces draft-snijders-idr-rfc8203bis instead of None |
2018-04-30
|
00 | Job Snijders | New version available: draft-ietf-idr-rfc8203bis-00.txt |
2018-04-30
|
00 | (System) | WG -00 approved |
2018-04-30
|
00 | Job Snijders | Set submitter to "Job Snijders ", replaces to draft-snijders-idr-rfc8203bis and sent approval email to group chairs: idr-chairs@ietf.org |
2018-04-30
|
00 | Job Snijders | Uploaded new revision |