Skip to main content

OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth
RFC 8330

Revision differences

Document history

Date Rev. By Action
2018-02-14
13 (System)
Received changes through RFC Editor sync (created alias RFC 8330, changed title to 'OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable …
Received changes through RFC Editor sync (created alias RFC 8330, changed title to 'OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth', changed abstract to 'A network may contain links with variable discrete bandwidth, e.g., microwave and copper.  The bandwidth of such links may change discretely in response to a changing external environment.  The word "availability" is typically used to describe such links during network planning.  This document defines a new type of Generalized Switching Capability-Specific Information (SCSI) TLV to extend the Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing protocol.  The extension can be used for route computation in a network that contains links with variable discrete bandwidth.  Note that this document only covers the mechanisms by which the availability information is distributed.  The mechanisms by which availability information of a link is determined and the use of the distributed information for route computation are outside the scope of this document.  It is intended that technology-specific documents will reference this document to describe specific uses.', changed pages to 10, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-02-14, changed IESG state to RFC Published)
2018-02-14
13 (System) RFC published
2018-02-08
13 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-02-02
13 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-01-24
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-01-24
13 (System) RFC Editor state changed to RFC-EDITOR from IANA
2018-01-24
13 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-01-24
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-01-23
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-01-23
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-01-22
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-01-22
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-01-09
13 (System) RFC Editor state changed to IANA from EDIT
2017-12-15
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2017-12-15
13 (System) IANA Action state changed to In Progress from On Hold
2017-12-13
13 (System) IANA Action state changed to On Hold from In Progress
2017-12-13
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2017-12-13
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2017-12-12
13 (System) RFC Editor state changed to EDIT
2017-12-12
13 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-12-12
13 (System) Announcement was received by RFC Editor
2017-12-12
13 (System) IANA Action state changed to In Progress
2017-12-12
13 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2017-12-12
13 Cindy Morgan IESG has approved the document
2017-12-12
13 Cindy Morgan Closed "Approve" ballot
2017-12-12
13 Cindy Morgan Ballot approval text was generated
2017-12-12
13 Cindy Morgan Ballot writeup was changed
2017-12-12
13 Deborah Brungard Ballot approval text was changed
2017-12-12
13 Deborah Brungard Last call announcement was changed
2017-12-12
13 Deborah Brungard Last call announcement was changed
2017-12-05
13 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-13.txt
2017-12-05
13 (System) New version approved
2017-12-05
13 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Alessandro D'Alessandro , Min Ye , Hao Long , Himanshu Shah
2017-12-05
13 Min Ye Uploaded new revision
2017-11-12
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-11-12
12 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-12.txt
2017-11-12
12 (System) New version approved
2017-11-12
12 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Alessandro D'Alessandro , Min Ye , Hao Long , Himanshu Shah
2017-11-12
12 Min Ye Uploaded new revision
2017-11-09
11 Adam Roach
[Ballot comment]
Thank you for addressing my discuss and most of my comments. I'll note that the following comment applied to two fields ("Availability level" …
[Ballot comment]
Thank you for addressing my discuss and most of my comments. I'll note that the following comment applied to two fields ("Availability level" and "LSP Bandwidth at Availability level n"), while the fix has only been applied to "Availability Level":

> Section 3.1 defines two fields as being "32-bit IEEE floaing point", which
> runs the risk of becoming ambiguous in the future (e.g., while no 32-bit
> decimal representations are currently defined, IEEE did define new, smaller
> formats in the most recent revision of IEEE 754). Additionally, byte ordering
> is important here. Recommend changing as:
>
> "This field is a binary32-format floating point number as defined by
> [IEEE754-2008]. The bytes are transmitted in network order; that is, the byte
> containing the sign bit is transmitted first."
2017-11-09
11 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2017-11-03
11 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2017-10-24
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-10-24
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-10-24
11 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-11.txt
2017-10-24
11 (System) New version approved
2017-10-24
11 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Alessandro D'Alessandro , Min Ye , Hao Long , Himanshu Shah
2017-10-24
11 Min Ye Uploaded new revision
2017-10-12
10 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2017-10-11
10 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-10-11
10 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2017-10-11
10 Jouni Korhonen Request for Telechat review by GENART Completed: Ready. Reviewer: Jouni Korhonen. Sent review to list.
2017-10-10
10 Ben Campbell
[Ballot comment]
I support Adam's DISCUSS.

It seems odd to find the terminology section before section 1.  Also, please consider using the boilerplate from 8174, …
[Ballot comment]
I support Adam's DISCUSS.

It seems odd to find the terminology section before section 1.  Also, please consider using the boilerplate from 8174, especially since there are lower case instances of at least "should".

I think the reference to RFC5920 needs to be normative, since reading that document seems necessary to understand the security considerations.
2017-10-10
10 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2017-10-10
10 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-10-10
10 Adam Roach
[Ballot discuss]
draft-ietf-teas-gmpls-scsi creates an IANA table "Generalized SCSI (Switching Capability Specific Information) TLVs Types" with a registration policy of "Specification Required."

This document adds …
[Ballot discuss]
draft-ietf-teas-gmpls-scsi creates an IANA table "Generalized SCSI (Switching Capability Specific Information) TLVs Types" with a registration policy of "Specification Required."

This document adds a value to this registry, and goes on to claim:

  The registration procedure for this registry is Standards Action as
  defined in [RFC8126].

"Standards Action" is not the same as "Specification Required."

Since *this* document is not defining the registry, it should not reiterate the policy -- in particular because the policy can get out of sync if specified in multiple locations, as in this case.
2017-10-10
10 Adam Roach
[Ballot comment]
Section 3.1 defines two fields as being "32-bit IEEE floaing point", which runs the risk of becoming ambiguous in the future (e.g., while …
[Ballot comment]
Section 3.1 defines two fields as being "32-bit IEEE floaing point", which runs the risk of becoming ambiguous in the future (e.g., while no 32-bit decimal representations are currently defined, IEEE did define new, smaller formats in the most recent revision of IEEE 754). Additionally, byte ordering is important here. Recommend changing as:

"This field is a binary32-format floating point number as defined by [IEEE754-2008]. The bytes are transmitted in network order; that is, the byte containing the sign bit is transmitted first." -- and, of course, add a citation for IEEE 754-2008 to the normative reference section.

Additionally, while recipient behavior is described for the error of sending multiple TLVs with the same availability (yay!), I think you also want text around handling of TLVs that contain unexpected values (e.g., Availability >= 1.0, and handling of values like INF, -INF, and NaN). Options would include ignoring the TLV, or rejecting the entire ICSD. I'm not sure which is more consistent with typical OSCF handling.

The reference for [GSCSI] is out of date. This is complicated by the fact that the title doesn't match, so finding the correct document is quite difficult. Please update to use "I-D.ietf-teas-gmpls-scsi-04" or something similar.

The IANA section is pretty confusing at the moment, as it claims "IANA has created...", even though the table in question is requested by draft-ietf-teas-gmpls-scsi. It's probably worth adding a note (with a "remove before publication") indicating that the registry will be created by draft-ietf-teas-gmpls-scsi, and that the requested value should be added to it when it is created.

____

Nits:

Please expand "TE" in the title.

Section 3.1:
  Type: 0x01, 16 bits.

As this is 16 bits, I recommend changing to: "0x0001, 16 bits"
2017-10-10
10 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2017-10-10
10 Alvaro Retana
[Ballot comment]
(1) Please include draft file names in the references, not just abbreviations.  That will make it easier to track the relationship and dependencies.  …
[Ballot comment]
(1) Please include draft file names in the references, not just abbreviations.  That will make it easier to track the relationship and dependencies.  For example, the draft uses the generalized format defined in draft-ietf-teas-gmpls-scsi, but the name of that draft (draft-ietf-teas-gmpls-scsi) doesn’t appear anywhere.  Also, the “References” and “Referenced by” tools in the datatracker don’t seem to work properly — in this case this document doesn’t appear to reference draft-ietf-teas-gmpls-scsi at all [A].

[A] https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/references/


(2) Section 3.2. (Processing Procedures): “This information MAY be used for path calculation by the node(s).”  I think that the “MAY” is out of place because this document already indicated that the use of the information is out of scope: s/MAY/may


(3) Also from 3.2:

  The Availability SCSI-TLV MUST NOT be sent in ISCDs with Switching
  Capability field values that have not been defined to support the
  Availability SCSI-TLV. Non-supporting nodes would see such as a
  malformed ISCD/LSA.

Where is this signaling defined?  How does a node know that others support the Availability ISCD/LSA?


(4) Section 4. (Security Considerations): “This document does not introduce security issues beyond those discussed in [RFC4203]…the extensions specified here have no direct effect on IP routing.”  But that is not true!  Even if out of scope of this document, the intent has already been established that the information can be used for route computation.  I think you should then expand on the impact that tampering/changing the LSAs could have.
2017-10-10
10 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2017-10-10
10 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2017-10-10
10 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2017-10-10
10 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2017-10-08
10 Alexey Melnikov
[Ballot comment]
This document should list the document that defines 32-bit IEEE floating point number as a Normative Reference, as it is required to implement …
[Ballot comment]
This document should list the document that defines 32-bit IEEE floating point number as a Normative Reference, as it is required to implement the draft.
2017-10-08
10 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2017-10-07
10 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2017-10-05
10 Mirja Kühlewind
[Ballot comment]
This could lead to random outcomes
"If multiple are present, only the first Availability
  SCSI-TLV for an availability level carried in the …
[Ballot comment]
This could lead to random outcomes
"If multiple are present, only the first Availability
  SCSI-TLV for an availability level carried in the same ISCD SHALL be
  processed. "
I would suggest the following instead:
"If multiple are present, the Availability
  SCSI-TLV with the lowest bandwidth value SHALL be
  processed. "

Nit:
In section 3.1 you may actually specify the actual length value as done for the type:
OLD
"Length: A 16 bits field that expresses the length of the TLV in
  bytes. "
NEW
"Length: 4 (bytes), 16 bits."
2017-10-05
10 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2017-09-28
10 Jean Mahoney Request for Telechat review by GENART is assigned to Jouni Korhonen
2017-09-28
10 Jean Mahoney Request for Telechat review by GENART is assigned to Jouni Korhonen
2017-09-27
10 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2017-09-26
10 Fatai Zhang
Document shepherd write-up for draft-ietf-ccamp-ospf-availability-extension-10.txt

> (1) What type of RFC is being requested (BCP, Proposed Standard,
>    Internet Standard, Informational, Experimental, or Historic)? …
Document shepherd write-up for draft-ietf-ccamp-ospf-availability-extension-10.txt

> (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 requested for publication as a Proposed Standard document.

This is appropriate because the document defines a new type of the
Generalized Switching Capability-specific information (SCSI) TLV to
extend the Open Shortest Path First (OSPF) routing protocol.

This track is noted in the document 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:

A network may contain links with variable discrete bandwidth, e.g., copper, radio, etc. The bandwidth of such links may change
discretely in reaction to changing external environment. Availability is typically used for describing such links during
network planning. This document defines a new type of the Generalized Switching Capability-specific information (SCSI) TLV to
extend the Open Shortest Path First (OSPF) routing protocol. The extension can be used for route computation in a network
that contains links with variable discrete bandwidth.

> Working Group Summary:

This document has been reviewed by both CCAMP and TEAS WGs and received some comments at IETF meetings and on the mailing list.Particularly, it was discussed how to organize the documents to make it generic to apply to multiple technologies,which leads to [draft-ietf-teas-gmpls-scsi].

This doucument was gone through by a joint WG last call between CCAMP and TEAS WGs.

There were no problems with consensus for this document.

> Document Quality:

The document is concise and only defines Availability sub-TLV as a sub-TLV of ISCD as defined in RFC4203.

> Personnel:

Fatai Zhang is the Document Shepherd
Deborah Brungard 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.

The document shepherd has reviewed the current revision of the
document and believes it is ready for publication.

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

No concerns.

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

> (6) Describe any specific concerns or issues that the Document
>    Shepherd has with this document that the Responsible Area
>    Director and/or the IESG should be aware of? For example,
>    perhaps he or she is uncomfortable with certain parts of the
>    document, or has concerns whether there really is a need for
>    it. In any event, if the WG has discussed those issues and
>    has indicated that it still wishes to advance the document,
>    detail those concerns here.

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

The WG chairs chased all authors and contributors for statements that
they had complied with IETF IPR policy. All responded. The replies have been tracked in the datatracker and can be found in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/history/

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

No disclosures have been made.

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

There has been substantial and broad review. There is good consensus
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 threats or 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.

No Nides found.

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

No such reviews needed.

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

All references correctly identified.

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

None such.

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

None.

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


> (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 section was fully reviewed by the document shepherd.  One new
allocation is requested in this document that is properly identified.

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

One new registry is requested and it requires Standards Action as
defined in [RFC5226].

> (19) Describe reviews and automated checks performed by the Document
>      Shepherd to validate sections of the document written in a
>      formal language, such as XML code, BNF rules, MIB definitions,
>      etc.

No such sections.

2017-09-26
10 Fatai Zhang
Document shepherd write-up for draft-ietf-ccamp-ospf-availability-extension-10.txt

> (1) What type of RFC is being requested (BCP, Proposed Standard,
>    Internet Standard, Informational, Experimental, or Historic)? …
Document shepherd write-up for draft-ietf-ccamp-ospf-availability-extension-10.txt

> (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 requested for publication as a Proposed Standard document.

This is appropriate because the document defines a new type of the
Generalized Switching Capability-specific information (SCSI) TLV to
extend the Open Shortest Path First (OSPF) routing protocol.

This track is noted in the document 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:

A network may contain links with variable discrete bandwidth, e.g., copper, radio, etc. The bandwidth of such links may change
discretely in reaction to changing external environment. Availability is typically used for describing such links during
network planning. This document defines a new type of the Generalized Switching Capability-specific information (SCSI) TLV to
extend the Open Shortest Path First (OSPF) routing protocol. The extension can be used for route computation in a network that contains links with
  variable discrete bandwidth.

> Working Group Summary:

This document has been reviewed by both CCAMP and TEAS WGs and received some comments at IETF meetings and on the mailing list.Particularly, it was discussed how to organize the documents to make it generic to apply to multiple technologies,which leads to [draft-ietf-teas-gmpls-scsi].

This doucument was gone through by a joint WG last call between CCAMP and TEAS WGs.

There were no problems with consensus for this document.

> Document Quality:

The document is concise and only defines Availability sub-TLV as a sub-TLV of ISCD as defined in RFC4203.

> Personnel:

Fatai Zhang is the Document Shepherd
Deborah Brungard 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.

The document shepherd has reviewed the current revision of the
document and believes it is ready for publication.

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

No concerns.

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

> (6) Describe any specific concerns or issues that the Document
>    Shepherd has with this document that the Responsible Area
>    Director and/or the IESG should be aware of? For example,
>    perhaps he or she is uncomfortable with certain parts of the
>    document, or has concerns whether there really is a need for
>    it. In any event, if the WG has discussed those issues and
>    has indicated that it still wishes to advance the document,
>    detail those concerns here.

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

The WG chairs chased all authors and contributors for statements that
they had complied with IETF IPR policy. All responded. The replies have been tracked in the datatracker and can be found in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/history/

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

No disclosures have been made.

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

There has been substantial and broad review. There is good consensus
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 threats or 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.

No Nides found.

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

No such reviews needed.

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

All references correctly identified.

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

None such.

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

None.

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


> (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 section was fully reviewed by the document shepherd.  One new
allocation is requested in this document that is properly identified.

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

One new registry is requested and it requires Standards Action as
defined in [RFC5226].

> (19) Describe reviews and automated checks performed by the Document
>      Shepherd to validate sections of the document written in a
>      formal language, such as XML code, BNF rules, MIB definitions,
>      etc.

No such sections.

2017-09-25
10 Deborah Brungard IESG state changed to IESG Evaluation from AD is watching
2017-09-25
10 Deborah Brungard Ballot has been issued
2017-09-25
10 Deborah Brungard Ballot writeup was changed
2017-09-25
10 Deborah Brungard Placed on agenda for telechat - 2017-10-12
2017-08-07
10 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-10.txt
2017-08-07
10 (System) New version approved
2017-08-07
10 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Min Ye , Alessandro D'Alessandro , Hao Long , Himanshu Shah
2017-08-07
10 Min Ye Uploaded new revision
2017-03-09
09 Gunter Van de Velde Closed request for Telechat review by OPSDIR with state 'Team Will not Review Version'
2017-03-03
09 Deborah Brungard Removed from agenda for telechat
2017-02-21
09 Jouni Korhonen Request for Telechat review by GENART Completed: Ready. Reviewer: Jouni Korhonen. Sent review to list.
2017-02-15
09 Jean Mahoney Request for Telechat review by GENART is assigned to Jouni Korhonen
2017-02-15
09 Jean Mahoney Request for Telechat review by GENART is assigned to Jouni Korhonen
2017-02-15
09 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Bert Wijnen
2017-02-15
09 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Bert Wijnen
2017-02-15
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-02-15
09 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-09.txt
2017-02-15
09 (System) New version approved
2017-02-15
09 (System) Request for posting confirmation emailed to previous authors: ccamp-chairs@ietf.org, "Alessandro D'Alessandro" , "Min Ye" , "Himanshu Shah" , "Gregory Mirsky" , "Hao Long"
2017-02-15
09 Min Ye Uploaded new revision
2017-02-14
08 Deborah Brungard Telechat date has been changed to 2017-03-16 from 2017-03-02
2017-02-06
08 Deborah Brungard Telechat date has been changed to 2017-03-02 from 2017-02-16
2017-02-05
08 Mehmet Ersue Request for Telechat review by OPSDIR Completed: Has Nits. Reviewer: Mehmet Ersue. Sent review to list.
2016-12-29
08 Jouni Korhonen Request for Telechat review by GENART Completed: Ready. Reviewer: Jouni Korhonen. Sent review to list.
2016-12-28
08 Deborah Brungard Telechat date has been changed to 2017-02-16 from 2017-01-05
2016-12-27
08 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2016-12-24
08 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Mehmet Ersue
2016-12-24
08 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Mehmet Ersue
2016-12-15
08 Jean Mahoney Request for Telechat review by GENART is assigned to Jouni Korhonen
2016-12-15
08 Jean Mahoney Request for Telechat review by GENART is assigned to Jouni Korhonen
2016-12-12
08 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Withdrawn'
2016-11-29
08 Deborah Brungard Telechat date has been changed to 2017-01-05 from 2016-12-15
2016-11-03
08 Deborah Brungard
As a result of Gen-ART review, the authors, chairs, and AD decided to send the document back to the WG to re-evaluate how to progress …
As a result of Gen-ART review, the authors, chairs, and AD decided to send the document back to the WG to re-evaluate how to progress the issues raised.
2016-11-03
08 Deborah Brungard Tag Revised I-D Needed cleared.
2016-11-03
08 Deborah Brungard IETF WG state changed to WG Document from Submitted to IESG for Publication
2016-11-03
08 Deborah Brungard IESG state changed to AD is watching::Revised I-D Needed from IESG Evaluation
2016-11-02
08 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2016-10-26
08 Deborah Brungard Telechat date has been changed to 2016-12-15 from 2016-11-03
2016-10-25
08 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2016-10-25
08 Deborah Brungard Ballot has been issued
2016-10-25
08 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2016-10-25
08 Deborah Brungard Created "Approve" ballot
2016-10-25
08 Deborah Brungard Ballot writeup was changed
2016-10-24
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2016-10-23
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2016-10-23
08 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-08.txt
2016-10-23
08 (System) New version approved
2016-10-23
07 (System) Request for posting confirmation emailed to previous authors: ccamp-chairs@ietf.org, "Alessandro D'Alessandro" , "Min Ye" , "Himanshu Shah" , "Gregory Mirsky" , "Hao Long"
2016-10-23
07 Min Ye Uploaded new revision
2016-10-20
07 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Rifaat Shekh-Yusef.
2016-10-20
07 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2016-10-20
07 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-ccamp-ospf-availability-extension-07.txt. If any part of this review is inaccurate, please let …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-ccamp-ospf-availability-extension-07.txt. If any part of this review is inaccurate, please let us know.

Upon approval of this document, we understand that there is one registry action to complete.

A new registry is to be created called the Types for sub-TLV of Interface Switching Capability Descriptor registry. This registry is to be a subregistry of the Open Shortest Path First (OSPF) Traffic Engineering TLVs registry located at:

http://www.iana.org/assignments/ospf-traffic-eng-tlvs/

The registry is to be managed via Standards Action as defined by RFC 5226.

There are initial registrations in the new registry as follows:

Type Description Reference
----------------+-------------------------------+-------------
0 Reserved [ RFC-TO-BE ]
0x01 Availability [ RFC-TO-BE ]

We understand that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI
2016-10-16
07 Jouni Korhonen Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Jouni Korhonen.
2016-10-14
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rifaat Shekh-Yusef
2016-10-14
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rifaat Shekh-Yusef
2016-10-14
07 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2016-10-14
07 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2016-10-13
07 Deborah Brungard Placed on agenda for telechat - 2016-11-03
2016-10-12
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2016-10-12
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2016-10-10
07 Cindy Morgan IANA Review state changed to IANA - Review Needed
2016-10-10
07 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ccamp-chairs@ietf.org, db3546@att.com, "Fatai Zhang" , ccamp@ietf.org, draft-ietf-ccamp-ospf-availability-extension@ietf.org, …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ccamp-chairs@ietf.org, db3546@att.com, "Fatai Zhang" , ccamp@ietf.org, draft-ietf-ccamp-ospf-availability-extension@ietf.org, zhangfatai@huawei.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (OSPF-TE Link Availability Extension for Links with Variable Discrete Bandwidth) to Proposed Standard


The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'OSPF-TE Link Availability Extension for Links with Variable Discrete
  Bandwidth'
  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-10-24. 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


  A network may contain links with variable discrete bandwidth, e.g.,
  copper, radio, etc. The bandwidth of such links may change
  discretely in reaction to changing external environment.
  Availability is typically used for describing such links during
  network planning. This document introduces an optional ISCD
  Availability sub-TLV to extend the Generalized Multi-Protocol Label
  Switching (GMPLS) Open Shortest Path First (OSPF) routing protocol.
  This extension can be used for route computation in a network that
  contains links with variable discrete bandwidth. Note, this document
  only covers the mechanisms by which the availability information is
  distributed. The mechanisms by which availability information of a
  link is determined and the use of the distributed information for
  route computation are outside the scope of this document.






The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/ballot/


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




2016-10-10
07 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2016-10-10
07 Deborah Brungard Last call was requested
2016-10-10
07 Deborah Brungard Ballot approval text was generated
2016-10-10
07 Deborah Brungard Ballot writeup was generated
2016-10-10
07 Deborah Brungard IESG state changed to Last Call Requested from AD Evaluation
2016-10-10
07 Deborah Brungard Last call announcement was generated
2016-10-08
07 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-07.txt
2016-10-08
07 (System) New version approved
2016-10-08
06 (System) Request for posting confirmation emailed to previous authors: ccamp-chairs@ietf.org, "Alessandro D'Alessandro" , "Min Ye" , "Himanshu Shah" , "Gregory Mirsky" , "Hao Long"
2016-10-08
06 Min Ye Uploaded new revision
2016-08-25
06 Fatai Zhang
Document shepherd write-up for draft-ietf-ccamp-ospf-availability-extension-06.txt


> (1) What type of RFC is being requested (BCP, Proposed Standard,
>    Internet Standard, Informational, Experimental, or Historic)? …
Document shepherd write-up for draft-ietf-ccamp-ospf-availability-extension-06.txt


> (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 requested for publication as a Proposed Standard document.

This is appropriate because the document defines the OSPF GMPLS encodings for TE links with variable discrete bandwidth.

This track is noted in the document 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:

A network may contain links with variable discrete bandwidth, e.g.,
copper, radio, etc. The bandwidth of such links may change
discretely in reaction to changing external environment.
This document introduces an optional ISCD Availability sub-TLV to
extend the OSPF GMPLS encodings for TE links with variable discrete bandwidth.
This extension can be used for route computation in a network that contains
links with variable discrete bandwidth.


> Working Group Summary:

This document has been reviewed by both CCAMP and TEAS WGs and received some comments at IETF meetings and on the mailing list.Particularly, it was discussed how to refine the documet to make it generic to apply to multiple technologies.

This doucument was gone through by a joint WG last call between CCAMP and TEAS WGs.

There were no problems with consensus for this document.

> Document Quality:

The document is concise and only defines Availability sub-TLV as a sub-TLV of ISCD as defined in RFC4203.

> Personnel:

Fatai Zhang is the Document Shepherd
Deborah Brungard 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.

The document shepherd has reviewed the current revision of the
document and believes it is ready for publication.

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

No concerns.

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

> (6) Describe any specific concerns or issues that the Document
>    Shepherd has with this document that the Responsible Area
>    Director and/or the IESG should be aware of? For example,
>    perhaps he or she is uncomfortable with certain parts of the
>    document, or has concerns whether there really is a need for
>    it. In any event, if the WG has discussed those issues and
>    has indicated that it still wishes to advance the document,
>    detail those concerns here.

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

The WG chairs chased all authors and contributors for statements that
they had complied with IETF IPR policy. All responded. The replies have been tracked in the datatracker and can be found in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/history/

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

No disclosures have been made.

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

There has been substantial and broad review. There is good consensus
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 threats or 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.

No Nides found.

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

No such reviews needed.

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

All references correctly identified.

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

None such.

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

None.

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


> (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 section was fully reviewed by the document shepherd.  One new
allocation is requested in this document that is properly identified.

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

One new registry is requested and it requires Standards Action as
defined in [RFC5226].

> (19) Describe reviews and automated checks performed by the Document
>      Shepherd to validate sections of the document written in a
>      formal language, such as XML code, BNF rules, MIB definitions,
>      etc.

No such sections.

2016-08-25
06 Deborah Brungard IESG state changed to AD Evaluation from AD is watching
2016-08-25
06 Deborah Brungard Tag Revised I-D Needed - Issue raised by AD cleared.
2016-08-25
06 Deborah Brungard IETF WG state changed to Submitted to IESG for Publication from WG Document
2016-08-19
06 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-06.txt
2016-08-05
05 Deborah Brungard Tag Revised I-D Needed - Issue raised by AD set.
2016-08-05
05 Deborah Brungard IETF WG state changed to WG Document from Submitted to IESG for Publication
2016-08-05
05 Deborah Brungard IESG state changed to AD is watching from Expert Review
2016-08-01
05 Deborah Brungard IESG state changed to Expert Review from Publication Requested
2016-07-27
05 Jonathan Hardwick Request for Early review by RTGDIR Completed: Not Ready. Reviewer: Jonathan Hardwick.
2016-07-11
05 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Jonathan Hardwick
2016-07-11
05 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Jonathan Hardwick
2016-06-14
05 Daniele Ceccarelli
Document shepherd write-up for draft-ietf-ccamp-ospf-availability-extension-05.txt


> (1) What type of RFC is being requested (BCP, Proposed Standard,
>    Internet Standard, Informational, Experimental, or Historic)? …
Document shepherd write-up for draft-ietf-ccamp-ospf-availability-extension-05.txt


> (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 requested for publication as a Proposed Standard document.

This is appropriate because the document defines the OSPF GMPLS encodings for TE links with variable discrete bandwidth.

This track is noted in the document 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:

A network may contain links with variable discrete bandwidth, e.g.,
copper, radio, etc. The bandwidth of such links may change
discretely in reaction to changing external environment.
This document introduces an optional ISCD Availability sub-TLV to
extend the OSPF GMPLS encodings for TE links with variable discrete bandwidth.
This extension can be used for route computation in a network that contains
links with variable discrete bandwidth.


> Working Group Summary:

This document has been reviewed by both CCAMP and TEAS WGs and received some comments at IETF meetings and on the mailing list.Particularly, it was discussed how to refine the documet to make it generic to apply to multiple technologies.

This doucument was gone through by a joint WG last call between CCAMP and TEAS WGs.

There were no problems with consensus for this document.

> Document Quality:

The document is concise and only defines Availability sub-TLV as a sub-TLV of ISCD as defined in RFC4203.

> Personnel:

Fatai Zhang is the Document Shepherd
Deborah Brungard 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.

The document shepherd has reviewed the current revision of the
document and believes it is ready for publication.

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

No concerns.

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

> (6) Describe any specific concerns or issues that the Document
>    Shepherd has with this document that the Responsible Area
>    Director and/or the IESG should be aware of? For example,
>    perhaps he or she is uncomfortable with certain parts of the
>    document, or has concerns whether there really is a need for
>    it. In any event, if the WG has discussed those issues and
>    has indicated that it still wishes to advance the document,
>    detail those concerns here.

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

The WG chairs chased all authors and contributors for statements that
they had complied with IETF IPR policy. All responded. The replies have been tracked in the datatracker and can be found in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/history/

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

No disclosures have been made.

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

There has been substantial and broad review. There is good consensus
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 threats or 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.

  ** The abstract seems to contain references ([RFC4203]), which it
    shouldn't. Please replace those with straight textual mentions of the
    documents in question.

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

No such reviews needed.

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

All references correctly identified.

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

None such.

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

None.

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


> (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 section was fully reviewed by the document shepherd.  One new
allocation is requested in this document that is properly identified.

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

One new registry is requested and it requires Standards Action as
defined in [RFC5226].

> (19) Describe reviews and automated checks performed by the Document
>      Shepherd to validate sections of the document written in a
>      formal language, such as XML code, BNF rules, MIB definitions,
>      etc.

No such sections.

2016-06-14
05 Daniele Ceccarelli Responsible AD changed to Deborah Brungard
2016-06-14
05 Daniele Ceccarelli IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2016-06-14
05 Daniele Ceccarelli IESG state changed to Publication Requested
2016-06-14
05 Daniele Ceccarelli IESG process started in state Publication Requested
2016-06-14
05 Daniele Ceccarelli Notification list changed to "Fatai Zhang" <zhangfatai@huawei.com>
2016-06-14
05 Daniele Ceccarelli Document shepherd changed to Fatai Zhang
2016-06-14
05 Daniele Ceccarelli Changed document writeup
2016-06-05
05 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-05.txt
2016-05-11
04 Daniele Ceccarelli
2016-05-11
04 Daniele Ceccarelli IETF WG state changed to In WG Last Call from WG Document
2016-05-11
04 Daniele Ceccarelli Changed consensus to Yes from Unknown
2016-05-11
04 Daniele Ceccarelli Intended Status changed to Proposed Standard from None
2016-02-22
04 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-04.txt
2015-10-18
03 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-03.txt
2015-07-05
02 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-02.txt
2015-03-05
01 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-01.txt
2014-10-27
00 Daniele Ceccarelli
2014-10-24
00 Lou Berger This document now replaces draft-long-ccamp-ospf-availability-extension instead of None
2014-10-08
00 Min Ye New version available: draft-ietf-ccamp-ospf-availability-extension-00.txt