Subject: [Teas] Fwd: Publication has been requested for draft-ietf-teas-interconnected-te-info-exchange-04

From: Lou Berger <[email-masked]>
Date: Tue, 22 Mar 2016 15:48:29 -0400

FYI

>
>
> -------- Forwarded Message --------
> Subject: 	Publication has been requested for
> draft-ietf-teas-interconnected-te-info-exchange-04
> Date: 	Tue, 22 Mar 2016 12:45:56 -0700
> From: 	Lou Berger <[email-masked]>
> To: 	[email-masked]
> CC: 	[email-masked], [email-masked], [email-masked],
> Lou Berger <[email-masked]>
>
>
>
> Lou Berger has requested publication of draft-ietf-teas-interconnected-te-info-exchange-04 as Best Current Practice on behalf of the TEAS working group.
>
> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/
>
>
>

Here's the document write up for reference.

>As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 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?
>

BCP - This document describes how existing tools/RFC can be used to
interconnect Traffic Engineered networks (domains).
 
> (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.
>

   This document sets out the problem statement and architecture for the
   exchange of TE information between interconnected TE networks in
   support of end-to-end TE path establishment. It describes how
   existing RFCs can be used to establish an end-to-end TE path with a
   set of constraints (such as bandwidth) across one or more network
   from a source to a destination.

> 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?

This document has been in process for a long time.  There were many
heated discussions that eventyually led to the this document which has a
high degree of support.  Recent delays were largely editorial rather
than in content. 

>
> 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?
>

This document has been discussed and reviewed by the WG many times.  It
has a wide scope and covers it comprehensively.  Having this information
consolidated in a single place has real value to the WG, users and
vendors. 

> Personnel
>
>   Who is the Document Shepherd?

Lou Berger

> Who is the Responsible Area Director?

Deborah Brungard

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

The document has been reviewed by the Shepherd while being developed as
well as in it's current form.  It is ready for publications

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
>

No

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

No concerns.  The document is in good shape for publication.

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

Yes.

>
> (8) Has an IPR disclosure been filed that references this document?

Yes.

> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

The IPR was discussed and the last messages on the topic stated:
1. https://www.ietf.org/mail-archive/web/teas/current/msg01038.html
   IPR was disclosed as required
2. https://www.ietf.org/mail-archive/web/teas/current/msg01037.html
   IPR on "BRPC" was also disclosed on RFC5441, back in 2007.

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

IMO strong concurrence.

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

The document has one idnits warning (a long line).

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>

No formal review required/appropriate.

> (13) Have all references within this document been identified as
> either normative or informative?
>

yes (although all marked as 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?
>

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

No, N/A.

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

This document describes how exsiting RFCs can be used so there are no
new IANA considerations.

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

None.

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

None needed.