Skip to main content

Shepherd writeup
draft-ietf-forces-lfb-lib

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

This document is a Standards Track document (Proposed Standard).
The title page of the draft reflects this RFC type. The choice
of standards track is a WG mandate to publish at least one LFB
document.

(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 defines basic classes of Logical Function Blocks (LFBs)
used in the Forwarding and Control Element Separation (ForCES).  The
basic LFB classes are defined according to ForCES FE model and ForCES
protocol specifications, and are scoped to meet requirements of
typical router functions and considered as the basic LFB library for
ForCES.  The library includes the descriptions of the LFBs and the
XML definitions.

Working Group Summary:
Standard WG discussions, nothing controversial.

Document Quality:
There are known implementations of this document.
Version 00 of this document was published in 2009 and has undergone
feedback based on implementation and architecture discussion.

Personnel:
Jamal Hadi Salim is the Document Shepherd. Adrian Farrel 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.

I reviewed the document and gave numerous feedback during its lifetime.
I validated the XML used.  I have implemented this LFB and validated
its definitions.
A couple of small changes exist; they could be added at
document publication time.

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

The document has had adequate review.
The document has undergone implementations.

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

The shepherd has no concerns.

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

We were waiting for one person who provided document review to
respond to the authors. The shepherd decided to go ahead and proceed with
publication regardless since the individual was a little hard to get hold
of over the last few months. There is still an opportunity on the IETF
wide last call; the shepherd will communicate with the person to make
them aware of this.

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

There are no IPR issues disclosed or known. The shepherd polled the
authors.

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

There is no IPR involved.

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

The WG consensus behind the document is strong.

(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 one has threatned an appeal or otherwise indicated extreme
discontent.

11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to
be thorough.

There are a few minor warning nits that could be fixed before
publication. There are of two types:
a) "weird spacing"
b) "unused reference"
c) Not found by the nits tool is the fact that section 3.1
 on line 261, a reference to RFC5812 is made when it should be
 a reference to RFC1812 (only off by 4000;->).

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

The document has an IANA considerations section that is appropriately
filled out. It does not require reviews related to MIBs.

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

yes.
All references are properly separated and labelled.

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

The publication of this document will not change the status of any
existing RFCs.

(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 adds to existing ForCES IANA registries and
introduces new registeries.
It adds definitions to LFB Class Names and LFB Class Identifiers
registery.
It adds 3 new registeries for holding:
a) Metadata ID, b) Exception ID and c) Validate Error ID.

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

IANA expert review is required for the new registeries described in #17
above.

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

The XML definitions have been vetted by various XML validators
against the ForCES model schema.
The XML defined in the document has also been verified by an
an implementations in which the Document Shepherd has been involved.

Back