Shepherd writeup

Shepherd Report: 
  (1.1) Who is the Document Shepherd for this document? 

Susan Hares( 
  (1.2) Who is the Responsible AD – Stewart Bryant. 

  (1.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.

This draft was the blue-print for the IDR changes. As such, it became the daily “to-list” for the time period August 2002 -2004. 

It would be inappropriate to have additional review of a document that was an approved discussion.  This document was reviewed extensively and daily during the revision IDR base document to RFC 4771 (2002-20040 

Making this document an RFC is simply a matter of formatting for RFC, and publishing the historic information. 
(1.4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?  

No. It was vetted by the list to contain the appropriate information. It has only been vetted for spelling for spelling and general format. It is a record of a historical discussion of changes to the BGP-4 draft. 

1.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.

It is the record of a discussion a mail list regarding BGP.  The authors did not censure the mail list. If other groups want to read the mail list and point out errors, we can add a “errata” section, but the email list should not be chosen. 

However, this is not a AAA, DNS, DHCP, XML, or internationalization normal review for a standards. 

1.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.

The important thing to note is this RFC is the key issues behind the revision of bgp-4 from RFC1771 to RFC4271.  As such, it records mail list discussions the list has to be transparent.  It is only records the discussion and action taken based on it in the revision. 

The text is a record of the issues discussed on IDR list. 

(1.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.

This is a record of the idr list. As such the IPR issues regarding the mail list is not appropriate since the IPR of a IETF mail list belongs to IETf.

(1.8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR

No – see 1.7. 

(1.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?   

Agreement that it was appropriate text, or debate occurred on list. 

(1.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 
        entered into the ID Tracker.) 

No – it is historical and informational as the record of the discussion on RFC 1771 for a revision of BGP-4 draft that became RFC4271.

(1.11) Has the Document Shepherd personally verified that the 
        document satisfies all ID nits? (See the Internet-Drafts Checklist 
        and Boilerplate checks are 
        not enough; this check needs to be thorough. Has the document 
        met all formal review criteria it needs to, such as the MIB 
        Doctor, media type and URI type reviews? 

OK – here I need help from my AD. The “submission” ID-NITs result was ] No nits found. The verbose – finds that it refers to RFC1771.  It was written during last revision of RFC1771 to RFC4271. I would like to get information on how to deal with this point. It is appropriate to have RFC1771 and RFC4271 be normative for the changes.  The tool does not consider this type of informational draft. 

I included the submission nits check below- which passes. The verbose work find an error with the normative reference to RFC1771(I did not include this). 

(1.12) Describe how the document meets any required formal review

criteria, such as the MIB Doctor, media type, and URI type reviews.

This is no applicable to this document.  

(1.13) Has the document split its references into normative and 

Yes, but the normative references to RFC1771 and RFC4271 seem appropriate. It appears this case was not considered in the ID-Nits tool.

The downward reference to RFC1771 is appropriate for this document.

[1.14] Are there normative references to documents that 
        are not ready for advancement or are otherwise in an unclear 

[RFC1771] is a downlevel reference, but is appropriate that this document be normative for this discussion. 

If such normative references exist, what is the strategy for their completion? 

Fix the ID-Nits Tool to handle this case. 

[1.15]Are there downward normative references, as described in [RFC3967]? If 
so, list these downward references to support the Area 
Director in the Last Call procedure for them [RFC3967]. 

	The RFC1771 is appropriate normative for this informational draft.
	The two normative documents are two BGP definitions:
a) RFC1771 and B) RFC4271.  The error report is in the Id-Nits tool.
[1.16] Will publication of this document change the status of any

existing RFCs? – no this will not change any status.  It is a record of the discussion that created RFC4271. 

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.

The document has the RFC references. 

(1.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 5226).

All references to protocol extensions I the document, and IANA registries were vetted with other drafts. This draft is simply a historical record of a mail list discussion. 

  (1.18) Has the Document Shepherd verified that sections of the 
        document that are written in a formal language, such as XML 
        code, BNF rules, MIB definitions, etc., validate correctly in 
        an automated checker?

	Yes, per the context of the document.  See above discussion. 
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 records the issues discussed and the consensus reached
   in the Inter-domain Routing (IDR) Working Group during its efforts  
   to revise and bring up to date the base specification for the BGP-4
   protocol as documented in RFC1771.  The document focuses on the
   changes tracked from August 2002 when the last major push for
   revision began. The results of these efforts are encoded in RFC4271,
   which should be taken as normative for any of the issues that were
   discussed.  The discussion here is intended to record how and why
   some of the changes to BGP were made.

     Working Group Summary 
This is a record of the WG discussion of the revisions of RFC1771 that generated RFC4271. The WG had consensus that this record was accurate. 

     Document Quality 

The record of a mail list discussion only a record of a mail list. 

idnits 2.12.13 


  Showing Errors (**), Warnings (==), and Comments (--).
  Errors MUST be fixed before draft submission.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see

     No issues found here.

  Checking nits according to

     No issues found here.

  Running in submission checking mode -- *not* checking nits according to .