OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth
draft-ietf-ccamp-ospf-availability-extension-13

[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."

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

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

[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"

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

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

[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."

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.

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.

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.

(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

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.

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.

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.

IPR poll (Daniele) https://mailarchive.ietf.org/arch/msg/ccamp/Pc1cq89lKw6gL6m9kJfwLUPgkzM

AUTHORS

Hao Long   Email: longhao@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/USOQi_-wnsaYW0Yln3tZ7W0gJPE
Min Ye   Email: amy.yemin@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/c2eNz6m6MLvkasETPmaAUjaQzMY
Greg Mirsky   Email: gregory.mirsky@ericsson.com https://mailarchive.ietf.org/arch/msg/ccamp/ZeI5FA8-UEK3v1OOHWRIZc8I7SE
Alessandro D'Alessandro   Email: alessandro.dalessandro@telecomitalia.it https://mailarchive.ietf.org/arch/msg/ccamp/BrURBwDpQcW2PQRPKelyFoltQgQ
Himanshu Shah   Email: hshah@ciena.com https://mailarchive.ietf.org/arch/msg/ccamp/s3Z7SS13wL2kVt_cVZ617k2diWA

IPR Poll (Deborah) http://www.ietf.org/mail-archive/web/ccamp/current/msg16391.html

Hao Long   Email: longhao@huawei.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16412.html
Min Ye   Email: amy.yemin@huawei.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16410.html
Greg Mirsky   Email: gregory.mirsky@ericsson.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16407.html
Alessandro D'Alessandro   Email: alessandro.dalessandro@telecomitalia.it http://www.ietf.org/mail-archive/web/ccamp/current/msg16414.html
Himanshu Shah   Email: hshah@ciena.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16405.html