BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions
draft-ietf-idr-te-pm-bgp-18

[Ballot comment]
Hello,

thank you for this document.
I only have caught nits.

Abstract:
s/Traffic Engineering Extensions/Traffic Engineering Metric Extensions/

To have a naming consistent with your references I'd do,
in section 2 and in IANA Section:
s/1120              Unidirectional Bandwidth Utilization/1120              Unidirectional Utilized Bandwidth/
and in Section 2.8:
s/| Unidirectional Bandwidth Utilization  |  39    |    33        |/| Unidirectional Utilized Bandwidth  |  39    |    33        |/

Not all figures are numbered. Either have numbering for all or for none. Since you never reference them, maybe you don't need numbering.
But if you keep it then:
  where:
                                Figure X
  Type: xxxx

should become:
                                Figure X
  where:
  Type: xxxx

[Ballot discuss]
How are the measurement interval(s) for these TLVs chosen?  I note that RFC
7810 (and 7810bis), as well as RFC 7471, include some text about
measurement intervals, in particular, a default value of 30 seconds and in
at least one case a requirement for configurability at sub-TLV granularity
(thus, TLV granularity for us here).  That said, it's not entirely clear to me whether
I'm supposed to treat the measurement intervals as also inherited from 7810bis/7471
as part of the "semantics of the value field".  It may be worth a brief clarifying note
in the top-level Section 2.

[Ballot comment]
I will be interested to see what the RFC Editor thinks about "the semantics
[...] are described in [I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471]", i.e.,
with both references containing the same content.  It's unclear that we
need to have a conversation about the apparent duplication at this point,
though.


This is pretty clearly looking at the barn door when the horse is long
gone, but the referenced semantics talk about setting the A bit for when
one or more measured values "exceed a configiured maximum threshold", text
that seems to apply even to the field "min delay".  Is the "exceeds"
supposed to interpreted as "outside the expected range, whether that is
numerically larger or smaller than the threshold value"?

Section 2.8

Would it help anyone to have the TLV tag values defined in this document
in the table as well?

Section 3

Thank you for adding the extra text recommended by the secdir reviewer!

[Ballot comment]
Hi, thanks for the work on this. I just have a couple of editorial comments:

- abstract: Please expand BGP-LS on first mention here and in the introduction. While BGP is listed as a well-known abbreviation in the registry, BGP-LS is not.

§1: Please expand BGP-LS and NLRI on first mention.

[Ballot comment]
I agree with Alexey (and Mirja?) - I had to go searching around to discover draft-ietf-lsr-isis-rfc7810bis -- a pointer would be helpful for those new to this...

[Ballot comment]
The document is rather terse in definition of A and RESERVED, so I wish it would have made it clearer to casual reader that all of them are defined in draft-ietf-lsr-isis-rfc7810bis.

[Ballot comment]
I know that this doc is only pointing to [I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471] for the definition of the respective metrics, however, there are IPPM RFCs for each of these metrics that provide further insights on how the calculate them correctly, e.g. rfc3393 IP Packet Delay Variation. I guess it could have been good to provide pointers to these RFCs but it also seems that this doc is the wrong doc of the set of three...

Also thanks for addressing the comments of the TSV-ART review (and thanks Yoshi for the review!)!

[Ballot comment]
I know that this doc is only pointing to [I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471] for the definition of the respective metrics, however, there are IPPM RFCs for each of these metrics that provide further insights on how the calculate them correctly, e.g. rfc3393 IP Packet Delay Variation. I guess it could have been good to provide pointers to these RFCs but it also seems that this doc is the wrong doc of the set of three...

[Ballot comment]
I know that this doc is only pointing to [I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471] for the definition of the respective metrics, however, there are are IPPM RFCs for each of these metrics that provide further insights on how the calculate them correctly, e.g. rfc3393 IP Packet Delay Variation. I guess it could have been good to provide pointers to these RFCs but it also seems that this doc is the wrong doc of the set of three...

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

The IANA Functions Operator has completed its review of draft-ietf-idr-te-pm-bgp-14. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs registry on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

https://www.iana.org/assignments/bgp-ls-parameters/

there are seven temporary assignments as follows:

TLV code-point Value
--------------------------------------------------------
1114 Unidirectional Link Delay
1115 Min/Max Unidirectional Link Delay
1116 Unidirectional Delay Variation
1117 Unidirectional Link Loss
1118 Unidirectional Residual Bandwidth
1119 Unidirectional Available Bandwidth
1120 Unidirectional Bandwidth Utilization

Each of these temporary registrations will be made permanent and their reference will be changed to [ RFC-to-be ].

The IANA Functions Operator understands 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 meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-12-12):

From: The IESG
To: IETF-Announce
CC: idr@ietf.org, draft-ietf-idr-te-pm-bgp@ietf.org, Susan Hares , idr-chairs@ietf.org, aretana.ietf@gmail.com, shares@ndzh.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BGP-LS Advertisement of IGP Traffic Engineering Performance Metric Extensions) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'BGP-LS Advertisement of IGP Traffic
Engineering Performance Metric
  Extensions'
  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 2018-12-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines new BGP-LS TLVs in order to carry the IGP
  Traffic Engineering Extensions defined in IS-IS and OSPF protocols.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-te-pm-bgp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-te-pm-bgp/ballot/


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

=== AD Review of draft-ietf-idr-te-pm-bgp-14 ===
https://mailarchive.ietf.org/arch/msg/idr/uMucYwPkjIBPM0ksK0dPhL9O9IU

Dear authors:

I just finished reading this document.  Please see the comments in-line below.

I found only one significant issue with the definition of Available Bandwidth (see my comment in §3.6).  This issue, along with my other comments (mostly nits), should be easy to address.  I am then starting the IETF Last Call.

Thanks!

Alvaro.


[Note: the line numbers come from idnits.]

...
17 Abstract

19   This document defines new BGP-LS TLVs in order to carry the IGP
20   Traffic Engineering Extensions defined in IS-IS and OSPF protocols.

[nit] s/defined in IS-IS and OSPF protocols/defined in the IS-IS and OSPF protocols

22 Requirements Language

24   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
25   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
26   "OPTIONAL" in this document are to be interpreted as described in BCP
27   14 [RFC2119] [RFC8174] when, and only when, they appear in all
28   capitals, as shown here.

[major] No Normative language is used -- which is not a bad thing.  Please remove the boilerplate text and the appropriate references.

...
90 2.  Link Attribute TLVs for TE Metric Extensions

92   The following new Link Attribute TLVs are defined:

94       TLV Name
95   ------------------------------------------
96     Unidirectional Link Delay

98     Min/Max Unidirectional Link Delay

100     Unidirectional Delay Variation

102     Unidirectional Link Loss

104     Unidirectional Residual Bandwidth

106     Unidirectional Available Bandwidth

108     Unidirectional Bandwidth Utilization

[nit] This is weird seemingly-stub section.  Consider renaming §3 "Link Attribute TLVs for TE Metric Extensions", moving the contents there and turning the list above into a table including the new TLV types...

110 3.  TLV Details

112 3.1.  Unidirectional Link Delay TLV

114   This TLV advertises the average link delay between two directly
115   connected IGP link-state neighbors.  The semantic of the TLV is
116   described in [RFC7810] and [RFC7471].

[nit] s/semantic/semantics

[minor nit] In rfc7810, the Type and Length fields are 1-byte each...so in reality rfc7810/rfc7471 describe the semantics of the Value field (not the whole TLV).  Maybe some short text in §3 about the TLV format following the specification in rfc7752 would help.


...
220 3.6.  Unidirectional Available Bandwidth TLV

222   This sub-TLV advertises the available bandwidth between two directly
223   connected IGP link-state neighbors.  The semantic of the TLV is
224   described in [RFC7810] and [RFC7471].

226     0                  1                  2                  3
227     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
228   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
229   |  Type                      |          Length                |
230   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
231   |                      Available Bandwidth                      |
232   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[major] AFAICT, Available Bandwidth is the only definition that is different between rfc7810/draft-ietf-lsr-isis-rfc7810bis and rfc7471.  The difference comes from the correction made to address this report [1].  Instead of trying to fix the definition here, I think that a similar report should be filed against rfc7471.  Please submit it and I will approve.

[1] https://www.rfc-editor.org/errata/eid5486


...
284 5.  IANA Considerations

286   This document requests assigning code-points from the registry "BGP-
287   LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
288   TLVs" for the new Link Attribute TLVs defined in the table below:

290     TLV code-point                Value
291   --------------------------------------------------------
292     1114              Unidirectional Link Delay

294     1115              Min/Max Unidirectional Link Delay

296     1116              Unidirectional Delay Variation

298     1117              Unidirectional Link Loss

300     1118              Unidirectional Residual Bandwidth

302     1119              Unidirectional Available Bandwidth

304     1120              Unidirectional Bandwidth Utilization

[major] This document doesn't request the assignments, but IANA has done the early allocation...  Please correct.


...
325 8.1.  Normative References
...
332   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
333               Border Gateway Protocol 4 (BGP-4)", RFC 4271,
334               DOI 10.17487/RFC4271, January 2006,
335               .

[minor] I think this can be an Informative reference: just like rfc4272 and rfc6952 are.

...
348   [RFC7810]  Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
349               Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
350               RFC 7810, DOI 10.17487/RFC7810, May 2016,
351               .

[major] Please use draft-ietf-lsr-isis-rfc7810bis as the reference.

Template version: RFC 4858,  2/24/2012

Status: 1) At Routing AD review
              2) secdir review issues  see thread:
https://www.ietf.org/mail-archive/web/idr/current/msg19953.html

=======================
(1)  Type
Type: Proposed standard
is it listed on front page: yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines new BGP-LS TLVs to carry the
information IGP  carry for traffic engineering extensions.
The traffic engineering extensions are defined by IS-IS and
OSPF.

Working Group Summary

This draft received moderate support (10+ people) on the
idr mail list. This draft is linked to OSPF/ISIS drafts.

Document Quality
  Are there existing implementations of the protocol? 
2 implementations from Cisco and Huawei:
(See IDR Wiki with report)
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-te-pm-bgp%20implementations


Personnel
  Document Shepherd?  Susan Hares
  Area Director: Alvaro Retana

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

Review the draft for text against the text in RFC7810 (ISIS),  draft-ietf-lsr-isis-rfc7810bis,
and RFC7471.    Reviewed NITS.  Queried authors on implementations.

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

Normal Directorate reviews should be done (RTG-DIR, OPS-DIR, SEC-DIR).
Please note that the security considerations state that the announcement of the
traffic engineering information does not have any other security issues over normal BGP.
The drasft also states that it is assumed that the IGPs this BGP-LS informaion have
"all the required secuirty and authentication mechnaisms (as describe din [RFC7810] and
[RFC7471] in order to prevent any security issues when propagating the TLVs into BGP-LS.

The authors feel this coveres the security  traffic engineering
information from an IGP  and the WG did not complain.
One particular author (Les Ginsberg) did not feel a revision of the
security considerations section.

The early  sec-dir early review found problems found nits
and was concerned regarding the vagueness of the RFC7752
security section.  Please see this discussion thread: 
https://www.ietf.org/mail-archive/web/idr/current/msg19953.html

Explanation for the IESG:
The shepherd disagreed with the authors on the quality of the
security consideration's section in draft-ietf-idr-te-pm-bgp.
One of the authors (Les Ginsberg) felt the  shepherd/WG chair
suggestion to revise the security consideratinos section was
unreasonable.  The resolution was to have an independent secdir review of this
draft that focused specifically on the security considerations.

Technical reasons behind the debate on draft-ietf-idr-te-pm-bgp:
Les Ginsberg feels that the RFC7752 security considerations
are sufficient to secure this information.  Both this shepherd and
the secdir reviewer have concerns regarding the vagueness in
the RFC7752 security considerations.  The RFC7752 security section does not
provide a restriction of this information to a trusted domain or
to isolated peers. The RFC7752 security section is vague.
The segment routing (SR) architecture (RFC8402) restricts
the default deployment of SR to a trusted domain.
The following BGP drafts for segment routing:
- draft-ietf-idr-bgpls-segment-routing-epe-17
- draft-ietf-idr-bgp-ls-segment-routing-ext-10
include the restrictiontion to a trusted domain with
specific BGP peer isolation.

The shepherd is hopeful that the Security Area ADs
and the secdir reviewer (Yoav Nir) will be able to make progress with
Les Ginsberg on  The shepherd respectfully suggests that Alvaro Retana
(Routing AD) and  the Security ADs (Benjamin Kaduk) continue to
support Yoav Nir in his discussion with regarding this matter.

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

These are BGP-LS TLVs.  See comments in #4.

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

This set of BGP-LS TLVs is just one of the groups of BGP-LS TLVs.

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

Les Ginsberg
IPR statement:
https://mailarchive.ietf.org/arch/msg/idr/4A4-ryLUKBO2-2if9xByH4sTIYE

S. Previdi
stefano previdi
IPR statement:
https://mailarchive.ietf.org/arch/msg/idr/3ko5DPmF-s5p4lS5HC-iK5mZD3I

Qin Wu:
IPR statement:
https://mailarchive.ietf.org/arch/msg/idr/ctEXG9kRUmIJXo_PwQT5SVcfmHE

Jeff Tantsura
Jeff Tantsura
IPR:
https://mailarchive.ietf.org/arch/msg/idr/Gi0YQFwCa5ox8LMsrCCDXeJ4xCM

C. Filsfils:
IPR:
https://mailarchive.ietf.org/arch/msg/idr/KZZnxmvmFB58JTs58YoCVswPVP0

John notes that he has posted previously.
https://mailarchive.ietf.org/arch/msg/idr/za0XkxCk-BGO496bMXnmGIWwW6U

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

No IPR disclosed.

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

Medium support 10-15 people.

(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 appeals or problems pending.

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

No nits.

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

No other formal review.

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

Yes - all references are normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All Normative references are at RFC level.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? 

No changes to existing document. 

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA considerations sections asks for allocation of code points from the
"BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"
registry.  These code points were assigned via early allocation.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries.

(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 automated checks needed

Template version: RFC 4858,  2/24/2012

(1)  Type
Type: Proposed standard
is it listed on front page: yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines new BGP-LS TLVs to carry the
information IGP  carry for traffic engineering extensions.
The traffic engineering extensions are defined by IS-IS and
OSPF.

Working Group Summary

This draft received moderate support (10+ people) on the
idr mail list. This draft is linked to OSPF/ISIS drafts.

Document Quality
  Are there existing implementations of the protocol? 
2 implementations from Cisco and Huawei:
(See IDR Wiki with report)
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-te-pm-bgp%20implementations


Personnel
  Document Shepherd?  Susan Hares
  Area Director: Alvaro Retana

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

Review the draft for text against the text in RFC7810 (ISIS),  draft-ietf-lsr-isis-rfc7810bis,
and RFC7471.    Reviewed NITS.  Queried authors on implementations.

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

Normal Directorate reviews should be done (RTG-DIR, OPS-DIR, SEC-DIR).
Please note that the security considerations state that the announcement of the
traffic engineering information does not have any other security issues over normal BGP.
The drasft also states that it is assumed that the IGPs this BGP-LS informaion have
"all the required secuirty and authentication mechnaisms (as describe din [RFC7810] and
[RFC7471] in order to prevent any security issues when propagating the TLVs into BGP-LS.

The authors feel this coveres the security  traffic engineering
information from an IGP  and the WG did not complain.
The shepherd would like a person on the security directorate person
with routing expertise to review this topic.

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

These are BGP-LS TLVs.  See comments in #4.

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

This set of BGP-LS TLVs is just one of the groups of BGP-LS TLVs.

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

Les Ginsberg
IPR statement:
https://mailarchive.ietf.org/arch/msg/idr/4A4-ryLUKBO2-2if9xByH4sTIYE

S. Previdi
stefano previdi
IPR statement:
https://mailarchive.ietf.org/arch/msg/idr/3ko5DPmF-s5p4lS5HC-iK5mZD3I

Qin Wu:
IPR statement:
https://mailarchive.ietf.org/arch/msg/idr/ctEXG9kRUmIJXo_PwQT5SVcfmHE

Jeff Tantsura
Jeff Tantsura
IPR:
https://mailarchive.ietf.org/arch/msg/idr/Gi0YQFwCa5ox8LMsrCCDXeJ4xCM

C. Filsfils:
IPR:
https://mailarchive.ietf.org/arch/msg/idr/KZZnxmvmFB58JTs58YoCVswPVP0

John notes that he has posted previously.
https://mailarchive.ietf.org/arch/msg/idr/za0XkxCk-BGO496bMXnmGIWwW6U

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

No IPR disclosed.

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

Medium support 10-15 people.

(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 appeals or problems pending.

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

No nits.

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

No other formal review.

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

Yes - all references are normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All Normative references are at RFC level.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? 

No changes to existing document. 

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.
The IANA considerations sections asks for allocation of code points from the
"BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"
registry.  These code points were assigned via early allocation.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries.

(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 automated checks needed

This draft await three things to go the IESG:
1) IPR Statement from C. Filsfils that is specifically on this draft,
2)  Editorial fix (see shepherd's report)
3) 2 implementations

Request for posting confirmation emailed to previous authors: Jeff Tantsura , idr-chairs@ietf.org, Les Ginsberg , Saikat Ray , Qin Wu , Hannes Gredler , Clarence Filsfils , Stefano Previdi

Request for posting confirmation emailed to previous authors: Les Ginsberg , Qin Wu , Hannes Gredler , Saikat Ray , Jeff Tantsura , Clarence Filsfils , Stefano Previdi

Request for posting confirmation emailed to previous authors: Les Ginsberg , Qin Wu , Hannes Gredler , Saikat Ray , Jeff Tantsura , Clarence Filsfils , Stefano Previdi

Request for posting confirmation emailed to previous authors: Qin Wu , Les Ginsberg , Saikat Ray , " jefftant@gmail.com" , Hannes Gredler , Clarence Filsfils , Stefano Previdi , idr-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Stefano Previdi , idr-chairs@ietf.org, Hannes Gredler , Saikat Ray , " jefftant@gmail.com" , Les Ginsberg , Clarence Filsfils , Qin Wu

Request for posting confirmation emailed to previous authors: Stefano Previdi , idr-chairs@ietf.org, Hannes Gredler , Saikat Ray , " jefftant@gmail.com" , Les Ginsberg , Clarence Filsfils , Qin Wu

Request for posting confirmation emailed to previous authors: " jefftant@gmail.com" , "Saikat Ray" , "Les Ginsberg" , "Hannes Gredler" , "Clarence Filsfils" , "Stefano Previdi" , "Qin Wu" , idr-chairs@ietf.org