Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)
draft-ietf-forces-interfelfb-06

[Ballot discuss]

I have two things I'd like to discuss:

(1) Section 10 says:

"
This document does not alter [RFC5812] or the ForCES
Protocol[RFC5810].  As such, it has no impact on these documents
security considerations.  This document simply defines the
operational parameters and capabilities of an LFB that performs LFB
class instance extensions across nodes under a single administrative
control.  This document does not attempt to analyze the presence or
possibility of security interactions created by allowing LFB graph
extension on packets.  Any such issues, if they exist should be
resolved by the designers of the particular data path i.e they are
not the responsibility of general mechanism outlined in this
document; one such option for protecting Ethernet is the use of IEEE
802.1AE Media Access Control Security [ieee8021ae] which provides
encryption and authentication.
"

I'm not sure I buy that explanation. While you may not be changing
the protocol much, you are sending PDUs over a network where they
previously were processed within one machine. IIRC, earlier ForCES
documents called for IPSec or TLS as mandatory-to-implement (MTI)
for anything where ForCES stuff was being sent "off the box." That
is clearly being done here, so I don't get how MACsec is now
regarded as optional to implement. Can you explain? That may be me
recalling incorrectly, or perhaps there is a good reason, but if the
above logic were correct there would have been no reason to have
said earlier that security was MTI so I'm confused.

(2) I'm also unsure that just saying "use MACsec" is enough to get
interop and security for this. For example, is it likely that
separate keys would be setup just for ForCES use here?  If so,
saying that's needed would be good. If not, I wonder what threats
might arise with spoofing ForCES traffic from a box that has the
right MACsec keys. Has someone implemented/tested with MACsec and
considered those issues?

[Ballot comment]

There are three places where there still seem to be comments in the
draft (marked by "XXX"), at least one of those looks like it ought
to have been sorted before now. I'm also not sure the others are
clear enough for the RFC editor. (Or perhaps for IANA, at whom they
may really be directed?)

[Ballot comment]
* I am not sure what the point of Section 9 is. There is not much IETF/IESG/IANA can do about this, can we? I think the authors/WG should take this up with the IEEE to get the required ethertype assigned before publication.

* It would have been nice to include a basic IPv6 router example in addition to (or even instead of) the basic IPv4 router example.

* I simply cannot visualize how the TLV encoded metadata format looks like inside the packet and how it saves 4 bytes per metadatum transferred. Specifically how does this differ from the encoding specified in section 6.2 of RFC5810 . Can you please clarify?

[Ballot comment]
"The Ethernet type is used to identify the frame as inter-FE LFB type.  Ethertype TBA1 is to be used (XXX: Note to RFC editor, likely we wont get that value - update when available)."  What is the status of the Ethertype registration with IEEE?  Obviously this document shouldn't be published without it.

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?

This is a working group approved document for a chartered item for the standards track.
This is proper for the document as it tries to standardize the interaction between ForCES forwarding elements.
The type of RFC is indicated in the title page header.

(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 describes extending the ForCES LFB topology across FEs
  i.e inter-FE connectivity without needing any changes to the ForCES
  specification by defining the Inter-FE LFB.  The Inter-FE LFB
  provides ability to pass data, metadata and exceptions across FEs.
  The document describes a generic way to transport the mentioned
  details but focuses on ethernet transport.

Working Group Summary

The document is straightforward, and there was no difficulty in coming
to consensus on all points described. There were discussion between a
couple of members of the working group, but all issues have been addressed
prior to this document being accepted as a working group document without any consensus issues.
At least one implementation has validated the features described in the document. 
There were no issues reported during the last call and therefore we believe the
working group is solidly behind this document.

Document Quality

  There is at least one implementation that has validated the features described
  in the document. At least one vendor has implemented the specification.

Personnel

  The Document Shepherd is Evangelos Haleplidis and the Responsible Area Director
  is Alia Atlas.

(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 document is ready for publication.
The author addressed all of the comments as well as incorporated satisfactory David Black's suggestions for congestion control.
There are minor nits that can be fixed during the RFC editor phase. There are also two notes for the editor. Both notes refer to the Ethertype value which should be given with the acceptance of this document.

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

No. The document has been reviewed, commented and revised several times.
In addition it has undergone further review from congestion control experts, the AD, the routing directorate and the Gen-ART reviewer.

(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. The XML has been verified by the schema both by software as well as by ForCES model experts.

(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 Document Shepherd has no concerns.
Regarding the congestion control applicability section, the authors have satisfactory defined the applicability of this document to belong strictly to Controlled Environment as per draft-ietf-tsvwg-rfc5405bis-10. In addition the authors have provided suggestions to mitigate potential issues with congestion traffic due to UDP usage.
"the Inter-FE LFB MUST only be deployed within a single
  network (with a single network operator) or networks of an adjacent
  set of cooperating network operators where traffic is managed to
  avoid congestion"
Both the AD and the Gen-ART reviewer made a notice about the Ethertype which was resolved using the proper IETF process for ethertypes within the text.

(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?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

The authors have confirmed that there is no 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? 

While the WG no longer exists, before the shutting down of the WG, the WG was solidly behind the document.
The document was reviewed and there were some discussions at the early stages of the document, which were addressed.
At the first Last Call, there was no issues reported, therefore it is the Shepherd's view
that the whole WG understood and agreed on the document.

The document underwent a second IETF last call after the wg was closed. Some editorial changes were requested by Alia Atlas (AD) and Russ Housely (Gen-Art reviewer), which will be address by the author prior to proceeding for publication.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are two nits.
1. A warning about weird spacing: '...putPort  group...' which can be fixed at the editing process of the document
2. 1 instance of lines with non-RFC2606-compliant FQDNs
3. A new reference has been added into the document but was not in the reference list.

(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 been written by an expert and the XML has been validated by the Document Shepherd.

(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? 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 changes to 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).

The IANA considerations are very well defined.
The document does not make any protocol extensions.
The referenced IANA registries have been clearly identified.
There is only an update on an existing registry for a new entry to be added. The new values are clearly defined.

(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 IANA registries are requested.

(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 Document Shepherd has validated the XML code based on the ForCES XML schema.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-forces-interfelfb-04.txt. If any part of this review is inaccurate, please let us know.

Upon approval of this document, IANA will register the following in the Logical Functional Block (LFB) Class Names and Class Identifiers registry at http://www.iana.org/assignments/forces:

LFB Class Identifier: 18 (suggested)
LFB Class Name: IFE
Version: 1.0
Description: An IFE LFB to standardize inter-FE LFB for ForCES Network Elements
Reference: [this document]

NOTE: We cannot guarantee that requested values will be assigned. If another document were to request this value, and be approved for publication first, the value would be registered to that document.

We understand that this is the only IANA action required by 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 only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

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?

This is a working group approved document for a chartered item for the standards track.
This is proper for the document as it tries to standardize the interaction between ForCES forwarding elements.
The type of RFC is indicated in the title page header.

(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 describes extending the ForCES LFB topology across FEs
  i.e inter-FE connectivity without needing any changes to the ForCES
  specification by defining the Inter-FE LFB.  The Inter-FE LFB
  provides ability to pass data, metadata and exceptions across FEs.
  The document describes a generic way to transport the mentioned
  details but focuses on ethernet transport.

Working Group Summary

The document is straightforward, and there was no difficulty in coming
to consensus on all points described. There were discussion between a
couple of members of the working group, but all issues have been addressed
prior to this document being accepted as a working group document without any consensus issues.
At least one implementation has validated the features described in the document. 
There were no issues reported during the last call and therefore we believe the
working group is solidly behind this document.

Document Quality

  There is at least one implementation that has validated the features described
  in the document. At least one vendor has implemented the specification.

Personnel

  The Document Shepherd is Evangelos Haleplidis and the Responsible Area Director
  is Alia Atlas.

(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 document is ready for publication.
The author addressed all of the comments as well as incorporated satisfactory David Black's suggestions for congestion control.
There are minor nits that can be fixed during the RFC editor phase. There are also two notes for the editor. Both notes refer to the Ethertype value which should be given with the acceptance of this document.

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

No. The document has been reviewed, commented and revised several times.
In addition it has undergone further review from congestion control experts, the AD and the Gen-ART reviewer.

(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. The XML has been verified by the schema both by software as well as by ForCES model experts.

(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 Document Shepherd has no concerns.
Regarding the congestion control applicability section, the authors have satisfactory defined the applicability of this document to belong strictly to Controlled Environment as per draft-ietf-tsvwg-rfc5405bis-10. In addition the authors have provided suggestions to mitigate potential issues with congestion traffic due to UDP usage.
"the Inter-FE LFB MUST only be deployed within a single
  network (with a single network operator) or networks of an adjacent
  set of cooperating network operators where traffic is managed to
  avoid congestion"
Both the AD and the Gen-ART reviewer made a notice about the Ethertype which was resolved using the proper IETF process for ethertypes within the text.

(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?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

The authors have confirmed that there is no 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? 

While the WG no longer exists, before the shutting down of the WG, the WG was solidly behind the document.
The document was reviewed and there were some discussions at the early stages of the document, which were addressed.
At the first Last Call, there was no issues reported, therefore it is the Shepherd's view
that the whole WG understood and agreed on the document.

The document underwent a second IETF last call after the wg was closed. Some editorial changes were requested by Alia Atlas (AD) and Russ Housely (Gen-Art reviewer), which will be address by the author prior to proceeding for publication.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are two nits.
1. A warning about weird spacing: '...putPort  group...' which can be fixed at the editing process of the document
2. 1 instance of lines with non-RFC2606-compliant FQDNs
3. A new reference has been added into the document but was not in the reference list.

(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 been written by an expert and the XML has been validated by the Document Shepherd.

(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? 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 changes to 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).

The IANA considerations are very well defined.
The document does not make any protocol extensions.
The referenced IANA registries have been clearly identified.
There is only an update on an existing registry for a new entry to be added. The new values are clearly defined.

(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 IANA registries are requested.

(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 Document Shepherd has validated the XML code based on the ForCES XML schema.

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?

This is a working group approved document for a chartered item for the standards track.
This is proper for the document as it tries to standardize the interaction between ForCES forwarding elements.
The type of RFC is indicated in the title page header.

(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 describes extending the ForCES LFB topology across FEs
  i.e inter-FE connectivity without needing any changes to the ForCES
  specification by defining the Inter-FE LFB.  The Inter-FE LFB
  provides ability to pass data, metadata and exceptions across FEs.
  The document describes a generic way to transport the mentioned
  details but focuses on ethernet transport.

Working Group Summary

The document is straightforward, and there was no difficulty in coming
to consensus on all points described. There were discussion between a
couple of members of the working group, but all issues have been addressed
prior to this document being accepted as a working group document without any consensus issues.
At least one implementation has validated the features described in the document. 
There were no issues reported during the last call and therefore we believe the
working group is solidly behind this document.

Document Quality

  There is at least one implementation that has validated the features described
  in the document. At least one vendor has implemented the specification.

Personnel

  The Document Shepherd is Evangelos Haleplidis and the Responsible Area Director
  is Alia Atlas.

(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 document is ready for publication.
The author addressed all of the comments as well as incorporated satisfactory David Black's suggestions for congestion control.
There are minor edits that can be fixed during the rfc editor phase. There are also two notes for the editor. Both notes refer to the Ethertype value which should be given with the acceptance of this document. These issues have been raised by both the AD as well as the Gen-ART reviewer.

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

No. The document has been reviewed, commented and revised several times.
In addition it has undergone further review from congestion control experts, the AD and the Gen-ART reviewer.

(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. The XML has been verified by the schema both by software as well as by ForCES model experts.

(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 Document Shepherd has no concerns.
Regarding the congestion control applicability section, the authors have satisfactory defined the applicability of this document to belong strictly to Controlled Environment as per draft-ietf-tsvwg-rfc5405bis-10. In addition the authors have provided suggestions to mitigate potential issues with congestion traffic due to UDP usage.
"the Inter-FE LFB MUST only be deployed within a single
  network (with a single network operator) or networks of an adjacent
  set of cooperating network operators where traffic is managed to
  avoid congestion"
Both the AD and the Gen-ART reviewer made a notice about the Ethertype which was resolved using the proper IETF process for ethertypes.

(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?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

The authors have confirmed that there is no 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? 

While the WG no longer exists, before the shutting down of the WG, the WG was solidly behind the document.
The document was reviewed and there were some discussions at the early stages of the document, which were addressed.
At the first Last Call, there was no issues reported, therefore it is the Shepherd's view
that the whole WG understood and agreed on the document.

The document underwent a second IETF last call after the wg was closed. Some editorial changes were requested by Alia Atlas (AD) and Russ Housely (Gen-Art reviewer), which will be address by the author prior to proceeding for publication.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are two nits.
1. A warning about weird spacing: '...putPort  group...' which can be fixed at the editing process of the document
2. 1 instance of lines with non-RFC2606-compliant FQDNs

(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 been written by an expert and the XML has been validated by the Document Shepherd.

(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? 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 changes to 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).

The IANA considerations are very well defined.
The document does not make any protocol extensions.
The referenced IANA registries have been clearly identified.
There is only an update on an existing registry for a new entry to be added. The new values are clearly defined.

(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 IANA registries are requested.

(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 Document Shepherd has validated the XML code based on the ForCES XML schema.

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ehalep@gmail.com, draft-ietf-forces-interfelfb@ietf.org, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ForCES Inter-FE LFB) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'ForCES Inter-FE LFB'
  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
ietf@ietf.org mailing lists by 2016-06-22. 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 describes how to extend the ForCES LFB topology across
  FEs by defining the Inter-FE LFB Class.  The Inter-FE LFB Class
  provides the ability to pass data and metadata across FEs without
  needing any changes to the ForCES specification.  The document
  focuses on Ethernet transport.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-forces-interfelfb/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-forces-interfelfb/ballot/


No IPR declarations have been submitted directly on this I-D.

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?

This is a working group approved document for a chartered item for the standards track.
This is proper for the document as it tries to standardize the interaction between ForCES forwarding elements.
The type of RFC is indicated in the title page header.

(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 describes extending the ForCES LFB topology across FEs
  i.e inter-FE connectivity without needing any changes to the ForCES
  specification by defining the Inter-FE LFB.  The Inter-FE LFB
  provides ability to pass data, metadata and exceptions across FEs.
  The document describes a generic way to transport the mentioned
  details but focuses on ethernet transport.

Working Group Summary

The document is straightforward, and there was no difficulty in coming
to consensus on all points described. There were discussion between a
couple of members of the working group, but all issues have been addressed
prior to this document being accepted as a working group document without any consensus issues.
At least one implementation has validated the features described in the document. 
There were no issues reported during the last call and therefore we believe the
working group is solidly behind this document.

Document Quality

  There is at least one implementation that has validated the features described
  in the document. At least one vendor has implemented the specification.

Personnel

  The Document Shepherd is Evangelos Haleplidis and the Responsible Area Director
  is Alia Atlas.

(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 document is ready for publication.
The author addressed all of the comments as well as incorporated satisfactory David Black's suggestions for congestion control.
There are minor edits that can be fixed during the rfc editor phase. There are also two notes for the editor. Both notes refer to the Ethertype value which should be given with the acceptance of this document.

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

No. The document has been reviewed, commented and revised several times.
In addition it has undergone further review from congestion control experts.

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

The Document Shepherd has no concerns.
Regarding the congestion control applicability section, the authors have satisfactory defined the applicability of this document to belong strictly to Controlled Environment as per draft-ietf-tsvwg-rfc5405bis-10. In addition the authors have provided suggestions to mitigate potential issues with congestion traffic due to UDP usage.
"the Inter-FE LFB MUST only be deployed within a single
  network (with a single network operator) or networks of an adjacent
  set of cooperating network operators where traffic is managed to
  avoid congestion"

(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?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

The authors have confirmed that there is no 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? 

While the WG no longer exists, before the shutting down of the WG, the WG was solidly behind the document.
The document was reviewed and there were some discussions at the early stages of the document, which were addressed.
At the Last Call, there was no issues reported, therefore it is the Shepherd's view
that the whole WG understood and agreed on the document.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are two nits.
1. A warning about weird spacing: '...putPort  group...' which can be fixed at the editing process of the document
2. 1 instance of lines with non-RFC2606-compliant FQDNs

(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 been written by an expert and the XML has been validated by the Document Shepherd.

(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? 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 changes to 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).

The IANA considerations are very well defined.
The document does not make any protocol extensions.
The referenced IANA registries have been clearly identified.
There is only an update on an existing registry for a new entry to be added. The new values are clearly defined.

(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 IANA registries are requested.

(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 Document Shepherd has validated the XML code based on the ForCES XML schema.

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?

This is a working group approved document for a chartered item for the standards track.
This is proper for the document as it tries to standardize the interaction between ForCES forwarding elements.
The type of RFC is indicated in the title page header.

(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 describes extending the ForCES LFB topology across FEs
  i.e inter-FE connectivity without needing any changes to the ForCES
  specification by defining the Inter-FE LFB.  The Inter-FE LFB
  provides ability to pass data, metadata and exceptions across FEs.
  The document describes a generic way to transport the mentioned
  details but focuses on ethernet transport.

Working Group Summary

The document is straightforward, and there was no difficulty in coming
to consensus on all points described. There were discussion between a
couple of members of the working group, but all issues have been addressed
prior to this document being accepted as a working group document without any consensus issues.
At least one implementation has validated the features described in the document. 
There were no issues reported during the last call and therefore we believe the
working group is solidly behind this document.

Document Quality

  There is at least one implementation that has validated the features described
  in the document. At least one vendor has implemented the specification.

Personnel

  The Document Shepherd is Evangelos Haleplidis and the Responsible Area Director
  is Alia Atlas.

(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 document is ready for publication.
The author addressed all of the comments as well as incorporated satisfactory David Black's suggestions for congestion control.
There are minor edits that can be fixed during the rfc editor phase. There are also two notes for the editor. Both notes refer to the Ethertype value which should be given with the acceptance of this document.

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

No. The document has been reviewed, commented and revised several times.
In addition it has undergone further review from congestion control experts.

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

The Document Shepherd has no concerns.
Regarding the congestion control applicability section, the authors have satisfactory defined the applicability of this document to Controlled Environment as per draft-ietf-tsvwg-rfc5405bis-10.

(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?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

The authors have confirmed that there is no 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? 

While the WG no longer exists, before the shutting down of the WG, the WG was solidly behind the document.
The document was reviewed and there were some discussions at the early stages of the document, which were addressed.
At the Last Call, there was no issues reported, therefore it is the Shepherd's view
that the whole WG understood and agreed on the document.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are two nits.
1. A warning about weird spacing: '...putPort  group...' which can be fixed at the editing process of the document
2. 1 instance of lines with non-RFC2606-compliant FQDNs

(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 been written by an expert and the XML has been validated by the Document Shepherd.

(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? 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 changes to 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).

The IANA considerations are very well defined.
The document does not make any protocol extensions.
The referenced IANA registries have been clearly identified.
There is only an update on an existing registry for a new entry to be added. The new values are clearly defined.

(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 IANA registries are requested.

(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 Document Shepherd has validated the XML code based on the ForCES XML schema.

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?

This is a working group approved document for a chartered item for the standards track.
This is proper for the document as it tries to standardize the interaction between ForCES forwarding elements.
The type of RFC is indicated in the title page header.

(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 describes extending the ForCES LFB topology across FEs
  i.e inter-FE connectivity without needing any changes to the ForCES
  specification by defining the Inter-FE LFB.  The Inter-FE LFB
  provides ability to pass data, metadata and exceptions across FEs.
  The document describes a generic way to transport the mentioned
  details but focuses on ethernet transport.

Working Group Summary

The document is straightforward, and there was no difficulty in coming
to consensus on all points described. There were discussion between a
couple of members of the working group, but all issues have been addressed
prior to this document being accepted as a working group document without any consensus issues.
At least one implementation has validated the features described in the document. 
There were no issues reported during the last call and therefore we believe the
working group is solidly behind this document.

Document Quality

  There is at least one implementation that has validated the features described
  in the document. At least one vendor has implemented the specification.

Personnel

  The Document Shepherd is Evangelos Haleplidis and the Responsible Area Director
  is Alia Atlas.

(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 document is ready for publication.
The author addressed all of the comments as well as incorporated satisfactory David Black's suggestions for congestion control.
There are minor edits that can be fixed during the rfc editor phase. There are also two notes for the editor. The notes refer to the Ethertype value which should be given with the acceptance of this document.

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

No. The document has been reviewed, commented and revised several times.
In addition it has undergone further review from congestion control experts.

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

The Document Shepherd has no concerns.

(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?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

The authors have confirmed that there is no 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? 

While the WG no longer exists, before the shutting down of the WG, the WG was solidly behind the document.
The document was reviewed and there were some discussions at the early stages of the document, which were addressed.
At the Last Call, there was no issues reported, therefore it is the Shepherd's view
that the whole WG understood and agreed on the document.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are two nits a warning

(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 been written by an expert and the XML has been validated by the Document Shepherd.

(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? 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 changes to 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).

The IANA considerations are very well defined.
The document does not make any protocol extensions.
The referenced IANA registries have been clearly identified.
There is only an update on an existing registry for a new entry to be added. The new values are clearly defined.

(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 IANA registries are requested.

(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 Document Shepherd has validated the XML code based on the ForCES XML schema.

Needs a serious rewrite and to explain the need for use of an Ethernet frame and how the forwarding works if there's no DSTFE or NEID and so on.

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?

This is a working group approved document for a chartered item for the standards track.
This is proper for the document as it tries to standardize the interaction between ForCES forwarding elements.
The type of RFC is indicated in the title page header.

(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 describes extending the ForCES LFB topology across FEs
  i.e inter-FE connectivity without needing any changes to the ForCES
  specification by defining the Inter-FE LFB.  The Inter-FE LFB
  provides ability to pass data, metadata and exceptions across FEs.
  The document describes a generic way to transport the mentioned
  details but focuses on ethernet transport.

Working Group Summary

The document is straightforward, and there was no difficulty in coming
to consensus on all points described. There were discussion between a
couple of members of the working group, but all issues have been addressed
prior to this document being accepted as a working group document without any consensus issues.
At least one implementation has validated the features described in the document. 
There were no issues reported during the last call and therefore we believe the
working group is solidly behind this document.

Document Quality

  There is at least one implementation that has validated the features described
  in the document. At least one vendor has implemented the specification.

Personnel

  The Document Shepherd is Evangelos Haleplidis and the Responsible Area Director
  is Alia Atlas.

(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 document is ready for publication. The following issues must be resolved prior to final publication (some are discussed later on in this write-up):
a) There is a error nit from idnits:
  ** Downref: Normative reference to an Informational RFC: RFC 3746

b) There a number of spelling errors. Please use https://tools.ietf.org/tools/idspell/webservice to fix.
For example:
1. "focusses" -> "focuses"
2. "ethernet" -> "Ethernet"
3. "metadatum" -> "Metadatum"
4. "learnt" -> "learned"
5. "Higig" -> "HiGig"

c) The ethernet type has not been finalized. This should be resolved prior to final publication.

d) There are a couple of editorial issues:
1. End of Page 3: "Details on how a graph of LFB class instances can be created can be derived by the..."
Please fix the:
can be created can be derived"

2. Page 6: "as well egress ports." -> "as well as egress ports." (same issue in page 9)

3. Page 7: "Each Network function." -> "Each Network Function."

4. Page 8: "The setup in Figure 3 can be split out across 3 FEs instead as
  demonstrated in Figure 4" -> "instead of"

5. Page 11: "This includes what of the of the original metadata" double "of the"

6. Page 24 - Last sentence "control. this" -> "control. This"

d) Use the newer version of the model (1.1)?

e) You need to change the IANA metadata ID request from "0x00000010" to "0x00000011". 0x00000010 has already been registered by RFC 7409.

f) In the XML, you have set the LFB class ID to 6612, but in the IANA request, you have requested the reservation of class ID 6112. Please select one. Also, can you use number 18 to be the next number in http://www.iana.org/assignments/forces/forces.xhtml#logical-types?

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

No. The document has been reviewed, commented and revised several times.

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

The Document Shepherd has no concerns.

(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?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

The authors have confirmed that there is no 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? 

The WG is solidly behind the document. The document has been reviewed and
there were some discussions at the early stages of the document, but these has been addressed.
At the Last Call, there was no issues reported, therefore it is the Shepherd's view
that the whole WG understand and agree on the document.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

One error nit: Downref: Normative reference to an Informational RFC: RFC 3746
see #15.

(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 been written by an expert and the XML has been validated by the Document Shepherd.

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

There is one error nit that must be addressed.

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

There is one downward reference to RFC 3746. RFC 3746 is the ForCES framework.

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

There are two major and one minor issue with the IANA considerations:

Major:
1. The IANA metadata ID request must be changed from "0x00000010" to "0x00000011". 0x00000010 has already been registered by RFC 7409.
2. In the XML, the LFB class ID is 6612, but in the IANA considerations, the request of the reservation is for class ID 6112.

Minor:
The authors may help IANA by preparing the table similar to how the registry is, to facilitate IANA.

(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 IANA registries are requested.

(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 Document Shepherd has validated the XML code based on the ForCES XML schema

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?

This is a working group approved document for a chartered item for the standards track.
This is proper for the document as it tries to standardize the interaction between ForCES forwarding elements.
The type of RFC is indicated in the title page header.

(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 describes extending the ForCES LFB topology across FEs
  i.e inter-FE connectivity without needing any changes to the ForCES
  specification by defining the Inter-FE LFB.  The Inter-FE LFB
  provides ability to pass data, metadata and exceptions across FEs.
  The document describes a generic way to transport the mentioned
  details but focuses on ethernet transport.

Working Group Summary

The document is straightforward, and there was no difficulty in coming
to consensus on all points described. There were discussion between a
couple of members of the working group, but all issues have been addressed
prior to this document being accepted as a working group document without any consensus issues.
At least one implementation has validated the features described in the document. 
There were no issues reported during the last call and therefore we believe the
working group is solidly behind this document.

Document Quality

  There is at least one implementation that has validated the features described
  in the document. At least one vendor has implemented the specification.

Personnel

  The Document Shepherd is Evangelos Haleplidis and the Responsible Area Director
  is Alia Atlas.

(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 document is almost ready for publication. The following issues must be resolved prior to publication (some are discussed later on in this write-up):
a) There is a error nit from idnits:
  ** Downref: Normative reference to an Informational RFC: RFC 3746

b) There a number of spelling errors. Please use https://tools.ietf.org/tools/idspell/webservice to fix.
For example:
1. "focusses" -> "focuses"
2. "ethernet" -> "Ethernet"
3. "metadatum" -> "Metadatum"
4. "learnt" -> "learned"
5. "Higig" -> "HiGig"

c) There are a couple of editorial issues:
1. End of Page 3: "Details on how a graph of LFB class instances can be created can be derived by the..."
Please fix the:
can be created can be derived"

2. Page 6: "as well egress ports." -> "as well as egress ports." (same issue in page 9)

3. Page 7: "Each Network function." -> "Each Network Function."

4. Page 8: "The setup in Figure 3 can be split out across 3 FEs instead as
  demonstrated in Figure 4" -> "instead of"

5. Page 11: "This includes what of the of the original metadata" double "of the"

6. Page 24 - Last sentence "control. this" -> "control. This"

d) Would it make sense to use the newer version of the model (1.1)?

e) You need to change the IANA metadata ID request from "0x00000010" to "0x00000011". 0x00000010 has already been registered by RFC 7409.

f) In the XML, you have set the LFB class ID to 6612, but in the IANA request, you have requested the reservation of class ID 6112. Please select one. Also, can you use number 18 to be the next number in http://www.iana.org/assignments/forces/forces.xhtml#logical-types?

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

No. The document has been reviewed, commented and revised several times.

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

The Document Shepherd has no concerns.

(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?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

The authors have confirmed that there is no 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? 

The WG is solidly behind the document. The document has been reviewed and
there were some discussions at the early stages of the document, but these has been addressed.
At the Last Call, there was no issues reported, therefore it is the Shepherd's view
that the whole WG understand and agree on the document.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

One error nit: Downref: Normative reference to an Informational RFC: RFC 3746
see #15.

(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 been writen by an expert and the XML has been validated by the Document Shepherd.

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

There is one error nit that must be addressed.

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

There is one downward reference to RFC 3746. RFC 3746 is the ForCES framework.

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

There are two major and one minor issue with the IANA considerations:

Major:
1. The IANA metadata ID request must be changed from "0x00000010" to "0x00000011". 0x00000010 has already been registered by RFC 7409.
2. In the XML, the LFB class ID is 6612, but in the IANA considerations, the request of the reservation is for class ID 6112.

Minor:
The authors may help IANA by preparing the table similar to how the registry is, to facilitate IANA.

(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 IANA registries are requested.

(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 Document Shepherd has validated the XML code based on the ForCES XML schema

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?

This is a working group approved document for a chartered item for the standards track.
This is proper for the document as it tries to standardize the interaction between ForCES forwarding elements.
The type of RFC is indicated in the title page header.

(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 describes extending the ForCES LFB topology across FEs
  i.e inter-FE connectivity without needing any changes to the ForCES
  specification by defining the Inter-FE LFB.  The Inter-FE LFB
  provides ability to pass data, metadata and exceptions across FEs.
  The document describes a generic way to transport the mentioned
  details but focuses on ethernet transport.

Working Group Summary

The document is straightforward, and there was no difficulty in coming
to consensus on all points described. There were discussion between a
couple of members of the working group, but all issues have been addressed
prior to this document being accepted as a working group document without any consensus issues.
At least one implementation has validated the features described in the document. 
There were no issues reported during the last call and therefore we believe the
working group is solidly behind this document.

Document Quality

  There is at least one implementation that has validated the features described
  in the document. At least one vendor has implemented the specification.

Personnel

  The Document Shepherd is Evangelos Haleplidis and the Responsible Area Director
  is Alia Atlas.

(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 document is almost ready for publication. The following issues must be resolved prior to publication (some are discussed later on in this write-up):
a) There is a error nit from idnits:
  ** Downref: Normative reference to an Informational RFC: RFC 3746

b) There a number of spelling errors. Please use https://tools.ietf.org/tools/idspell/webservice to fix.
For example:
1. "focusses" -> "focuses"
2. "ethernet" -> "Ethernet"
3. "metadatum" -> "Metadatum"
4. "learnt" -> "learned"
5. "Higig" -> "HiGig"

c) There are a couple of editorial issues:
1. End of Page 3: "Details on how a graph of LFB class instances can be created can be derived by the..."
Please fix the:
can be created can be derived"

2. Page 6: "as well egress ports." -> "as well as egress ports." (same issue in page 9)

3. Page 7: "Each Network function." -> "Each Network Function."

4. Page 8: "The setup in Figure 3 can be split out across 3 FEs instead as
  demonstrated in Figure 4" -> "instead of"

5. Page 11: "This includes what of the of the original metadata" double "of the"

6. Page 24 - Last sentence "control. this" -> "control. This"

d) Would it make sense to use the newer version of the model (1.1)?

e) You need to change the IANA metadata ID request from "0x00000010" to "0x00000011". 0x00000010 has already been registered by RFC 7409.

f) In the XML, you have set the LFB class ID to 6612, but in the IANA request, you have requested the reservation of class ID 6112. Please select one.

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

No. The document has been reviewed, commented and revised several times.

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

The Document Shepherd has no concerns.

(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?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

The authors have confirmed that there is no 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? 

The WG is solidly behind the document. The document has been reviewed and
there were some discussions at the early stages of the document, but these has been addressed.
At the Last Call, there was no issues reported, therefore it is the Shepherd's view
that the whole WG understand and agree on the document.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

One error nit: Downref: Normative reference to an Informational RFC: RFC 3746
see #15.

(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 been writen by an expert and the XML has been validated by the Document Shepherd.

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

There is one error nit that must be addressed.

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

There is one downward reference to RFC 3746. RFC 3746 is the ForCES framework.

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

There are two major and one minor issue with the IANA considerations:

Major:
1. The IANA metadata ID request must be changed from "0x00000010" to "0x00000011". 0x00000010 has already been registered by RFC 7409.
2. In the XML, the LFB class ID is 6612, but in the IANA considerations, the request of the reservation is for class ID 6112.

Minor:
The authors may help IANA by preparing the table similar to how the registry is, to facilitate IANA.

(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 IANA registries are requested.

(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 Document Shepherd has validated the XML code based on the ForCES XML schema