Use Cases for Data Center Network Virtualization Overlay Networks
draft-ietf-nvo3-use-case-17

[Ballot comment]
Thanks for adressing the tsv-art review and my additional comments. Thanks again to David!

I still agree with Alvaro and Suresh that this document doesn't seem to be very useful as a stand alone document, given that it does not state requirements clearly. To me it is still not clear if nvo3 networks are actually that much different compared to existing virtual networks such that any additional protocol work is needed.

------------------
For you convince, I post David's full review here:

Review result: Has Issues

I've reviewed this document as part of TSV-ART's ongoing effort to
review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors
for their information and to allow them to address any issues raised.
Please always CC tsv-art at ietf.org if you reply to or forward this
review.

This draft describes use cases for Data-Center Network Virtualization over
Layer 3 (NVO3) technology being worked on the NVO3 WG.

I should apologize for this review coming relatively late - the desirability
of a TSV-ART review of this draft was not discovered until after IETF Last
Call had concluded, and actually not until after an initial TSV-ART decision
had been made to not review this draft.

In the spirit of full disclosure, I have been an active member of the NVO3
WG, and an author of two of its three published RFCs, RFC 7364 and RFC
8014.  I have not seen much value in this use case draft, and for that
reason I did not carefully review it in the WG.  I have no fundamental
objection to RFC publication of this draft, but having reviewed it in detail
now, I believe it needs some serious attention before being approved for
RFC publication, and hope that the IESG concurs.

-- TSV-ART review comments:

[T-1] There's one minor transport issue in this draft that requires correction
in Section 2. Basic NVO3 Networks:

  The TS reachability update mechanisms need be fast enough so that
  the updates do not cause any communication disruption/interruption.

That requirement is overstated.  NVO3 technology can and does disrupt
communication by dropping packets when a TS (e.g., a virtual machine)
moves to a different network attachment point (i.e., NVE).

This requirement should be restated in terms of disruption to transport
protocols - it's ok to drop a packet or two thereby causing a TCP or SCTP
retransmission, but dropping enough packets to cause termination of
a TCP connection or SCTP association is clearly unacceptable.
In contrast, UDP-based applications will see packet drops in this (and other)
scenarios, but avoidance of that is not an NVO3 goal - while the U in UDP
does not stand for Unreliable, in NVO3 context, this is a good way to
think about that letter .

-- Other review comments

- Major Issue

[A] Section 2 of the draft is a problem.  While Section 1 characterizes
Section 2 as describing a use case referred to as "DC East-West traffic," that
use case is not to be found in Section 2 (e.g., nothing in Section 2 appears
to distinguish East-West traffic from North-South traffic).  In its current
form, Section 2 is really an NVO3 Background section, as it describes
NVO3 terminology in general terms - while it uses different text, nearly
all of the material that it contains can be found elsewhere, e.g., RFC 8014
on NVO3 Architecture (NB: This reviewer is an author of RFC 8014).  Section
2's title should be changed to "NVO3 Background" or something similar,
and Section 1 changed accordingly.

- Minor issues

[1] The draft's use of the term "NVO3 network" is sloppy and imprecise.
This is actually an NVO3 Virtual Network or VN - the word "virtual"
should be inserted in all cases.

[2] This text in section 3 is vague on what a VPN is:

  This, in turn,
  becomes the case of interconnecting an NVO3 network and the virtual
  private network (VPN) on the Internet or wide-area networks (WAN).
  Note that a VPN is not implemented by NVO3 solution.

By itself, the latter sentence is incorrect, however, reading onward, one
discovers that not all forms of VPNs are intended - section 3.1 uses an
IPsec VPN, and section 3.2 uses a BGP/MPLS L3VPN.  I would suggest
deleting the second sentence and rewriting the first to use these two
technologies as an example, e.g.:

  WAN connectivity to the virtual gateway can be provided by VPN
  technologies such as IPsec VPNs [RFC4301] and BGP/MPLS IP
  VPNs [RFC 4364].

[3] The first paragraph in section 3.2 is very hard to understand for someone
who is not already an expert in BGP/MPLS VPNs (RFC 4364 & RFC 7432) - e.g.,
it contains many unexpanded acronyms from that domain - ASBR, PE, SP, etc.,
none of which appear in this draft's terminology section.  It is not reasonable
for a general use case draft such as this to assume that degree of expertise
in another technical domain.

[4] As written, this sentence in Section 4.2 is incorrect:

  As a result, a tunnel carrying NVO3
  network traffic must be terminated at the GW/firewall where the NVO3
  traffic is processed.

as there are deployed "running code" counterexamples.

The underlying problem appears to be that the use case in section 4.2 includes
an implicit, but unstated, requirement for physical network segmentation/
isolation via physical GW/firewall network nodes.  That requirement needs to
be stated, and I suggest changing the section title to somehow convey this
physical segmentation/isolation requirement.

- Editorial

In Section 1. Introduction:

  The goal of
  data center network virtualization overlay (NVO3) networks is to
  decouple the communication among tenant systems from DC physical
  infrastructure networks and to allow one physical network
  infrastructure:

Pluralize and edit to "The goals of ... are ... infrastructure to:" and edit
the bulleted list so that each list item is a grammatically correct
completion of this sentence in the singular (i.e., "The goal of ... is to:").

The paragraph about gateways in the Introduction ("An NVO3 network
may interconnect ..." seems out of place - try moving it to somewhere
in Section 2, e.g., so that it comes after the definition of the vGW
acronym in the terminology section.

In Section 1.1 Terminology:

- DMZ definition should use the relative terms "more trusted" and
  "less trusted" in place of the absolute terms "trusted" and "untrusted"

- In DC Operator definition: "A role who" -> "An entity that"  That wording
  should also be used instead of "A company that" in the definition of
  DC Provider.

Some usage of NVO3 terminology, while correct, makes this draft less
accessible to those not familiar with the NVO3 WG.  TS (Tenant System)
is a particular problem although this sentence near the start of Section 2
that introduces the term is fine:

  A TS can be a physical server/device or a virtual machine (VM)
  on a server, i.e., end-device [RFC7365].

I would suggest that the draft be written in terms of Virtual Machines
beyond this point, with a sentence added after the above sentence to
say that the draft is written in terms of virtual machines as a motivating
example of TSs for clarity, but the use cases apply to TSs in general, not
just VMs.

In section 4.1, use "physical servers" instead of "metal servers."    The
latter isn't even a good term - "bare metal servers" was probably intended,
but "physical servers" is the better term.

In section 5 Summary, remove the following paragraph:

  DC services may vary, from infrastructure as a service (IaaS), to
  platform as a service (PaaS), to software as a service (SaaS).
  In these services, NVO3 networks are just a portion of such services.

as those *aaS terms occur nowhere else in the draft, and hence this text
doesn't summarize any prior material.

Thanks, --David

[Ballot comment]
This draft doesn't seem to be aimed at requirements, so my no objection is on that basis.  I would expect a completely different document if requirements were included.

[Ballot comment]
I agree with Mirja that David Black's TSV-ART review (included as a Comment in Mirja's ballot) is worth a look before the draft goes to the RFC Editor.

To the IESG: I don't object to the publication of this document, but my impression was that much of the text is describing use cases for NVO3 products, with less attention being paid to unique requirements of each use case for protocol work in the IETF, which is why IETF working groups need to think about use cases in the first place. Maybe that's worth keeping in mind for any future use case drafts that the IESG will be evaluating?

Additional comment: I'm getting the following error message from my ballot e-mail, just FYI.

(expanded from
    ): host
    aspmx.l.google.com[173.194.208.26] said: 550-5.1.1 The email account that
    you tried to reach does not exist. Please try 550-5.1.1 double-checking the
    recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn
    more at 550 5.1.1  https://support.google.com/mail/?p=NoSuchUser
    z201si2542080qkz.244 - gsmtp (in reply to RCPT TO command)

[Ballot comment]
I agree with Mirja that David Black's TSV-ART review (included as a Comment in Mirja's ballot) is worth a look before the draft goes to the RFC Editor.

To the IESG: I don't object to the publication of this document, but my impression was that much of the text is describing use cases for NVO3 products, with less attention being paid to unique requirements of each use case for protocol work in the IETF, which is why IETF working groups need to think about use cases in the first place. Maybe that's worth keeping in mind for any future use case drafts that the IESG will be evaluating?

[Ballot discuss]
I agree with Alvaro and Suresh that this document doesn't seem to be very useful as a stand alone document. However, if published it should at least state requirements clearly. There is one specific transport requirement on timing as stated in David Black's transport review (Thanks!) that must be addressed before publication but other parts could also benefit from stating requirements explicitly and clearly (also see some comment in David's review). It also not clear what these use cases and potential requirements derived from them means in terms of needed protocol work in nvo3. From me it's not clear at all if nvo3 networks are actually that much different compared to existing virtual networks such that any additional protocol work is needed.

[Ballot comment]
For you convince, I post David's full review here:

Review result: Has Issues

I've reviewed this document as part of TSV-ART's ongoing effort to
review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors
for their information and to allow them to address any issues raised.
Please always CC tsv-art at ietf.org if you reply to or forward this
review.

This draft describes use cases for Data-Center Network Virtualization over
Layer 3 (NVO3) technology being worked on the NVO3 WG.

I should apologize for this review coming relatively late - the desirability
of a TSV-ART review of this draft was not discovered until after IETF Last
Call had concluded, and actually not until after an initial TSV-ART decision
had been made to not review this draft.

In the spirit of full disclosure, I have been an active member of the NVO3
WG, and an author of two of its three published RFCs, RFC 7364 and RFC
8014.  I have not seen much value in this use case draft, and for that
reason I did not carefully review it in the WG.  I have no fundamental
objection to RFC publication of this draft, but having reviewed it in detail
now, I believe it needs some serious attention before being approved for
RFC publication, and hope that the IESG concurs.

-- TSV-ART review comments:

[T-1] There's one minor transport issue in this draft that requires correction
in Section 2. Basic NVO3 Networks:

  The TS reachability update mechanisms need be fast enough so that
  the updates do not cause any communication disruption/interruption.

That requirement is overstated.  NVO3 technology can and does disrupt
communication by dropping packets when a TS (e.g., a virtual machine)
moves to a different network attachment point (i.e., NVE).

This requirement should be restated in terms of disruption to transport
protocols - it's ok to drop a packet or two thereby causing a TCP or SCTP
retransmission, but dropping enough packets to cause termination of
a TCP connection or SCTP association is clearly unacceptable.
In contrast, UDP-based applications will see packet drops in this (and other)
scenarios, but avoidance of that is not an NVO3 goal - while the U in UDP
does not stand for Unreliable, in NVO3 context, this is a good way to
think about that letter .

-- Other review comments

- Major Issue

[A] Section 2 of the draft is a problem.  While Section 1 characterizes
Section 2 as describing a use case referred to as "DC East-West traffic," that
use case is not to be found in Section 2 (e.g., nothing in Section 2 appears
to distinguish East-West traffic from North-South traffic).  In its current
form, Section 2 is really an NVO3 Background section, as it describes
NVO3 terminology in general terms - while it uses different text, nearly
all of the material that it contains can be found elsewhere, e.g., RFC 8014
on NVO3 Architecture (NB: This reviewer is an author of RFC 8014).  Section
2's title should be changed to "NVO3 Background" or something similar,
and Section 1 changed accordingly.

- Minor issues

[1] The draft's use of the term "NVO3 network" is sloppy and imprecise.
This is actually an NVO3 Virtual Network or VN - the word "virtual"
should be inserted in all cases.

[2] This text in section 3 is vague on what a VPN is:

  This, in turn,
  becomes the case of interconnecting an NVO3 network and the virtual
  private network (VPN) on the Internet or wide-area networks (WAN).
  Note that a VPN is not implemented by NVO3 solution.

By itself, the latter sentence is incorrect, however, reading onward, one
discovers that not all forms of VPNs are intended - section 3.1 uses an
IPsec VPN, and section 3.2 uses a BGP/MPLS L3VPN.  I would suggest
deleting the second sentence and rewriting the first to use these two
technologies as an example, e.g.:

  WAN connectivity to the virtual gateway can be provided by VPN
  technologies such as IPsec VPNs [RFC4301] and BGP/MPLS IP
  VPNs [RFC 4364].

[3] The first paragraph in section 3.2 is very hard to understand for someone
who is not already an expert in BGP/MPLS VPNs (RFC 4364 & RFC 7432) - e.g.,
it contains many unexpanded acronyms from that domain - ASBR, PE, SP, etc.,
none of which appear in this draft's terminology section.  It is not reasonable
for a general use case draft such as this to assume that degree of expertise
in another technical domain.

[4] As written, this sentence in Section 4.2 is incorrect:

  As a result, a tunnel carrying NVO3
  network traffic must be terminated at the GW/firewall where the NVO3
  traffic is processed.

as there are deployed "running code" counterexamples.

The underlying problem appears to be that the use case in section 4.2 includes
an implicit, but unstated, requirement for physical network segmentation/
isolation via physical GW/firewall network nodes.  That requirement needs to
be stated, and I suggest changing the section title to somehow convey this
physical segmentation/isolation requirement.

- Editorial

In Section 1. Introduction:

  The goal of
  data center network virtualization overlay (NVO3) networks is to
  decouple the communication among tenant systems from DC physical
  infrastructure networks and to allow one physical network
  infrastructure:

Pluralize and edit to "The goals of ... are ... infrastructure to:" and edit
the bulleted list so that each list item is a grammatically correct
completion of this sentence in the singular (i.e., "The goal of ... is to:").

The paragraph about gateways in the Introduction ("An NVO3 network
may interconnect ..." seems out of place - try moving it to somewhere
in Section 2, e.g., so that it comes after the definition of the vGW
acronym in the terminology section.

In Section 1.1 Terminology:

- DMZ definition should use the relative terms "more trusted" and
  "less trusted" in place of the absolute terms "trusted" and "untrusted"

- In DC Operator definition: "A role who" -> "An entity that"  That wording
  should also be used instead of "A company that" in the definition of
  DC Provider.

Some usage of NVO3 terminology, while correct, makes this draft less
accessible to those not familiar with the NVO3 WG.  TS (Tenant System)
is a particular problem although this sentence near the start of Section 2
that introduces the term is fine:

  A TS can be a physical server/device or a virtual machine (VM)
  on a server, i.e., end-device [RFC7365].

I would suggest that the draft be written in terms of Virtual Machines
beyond this point, with a sentence added after the above sentence to
say that the draft is written in terms of virtual machines as a motivating
example of TSs for clarity, but the use cases apply to TSs in general, not
just VMs.

In section 4.1, use "physical servers" instead of "metal servers."    The
latter isn't even a good term - "bare metal servers" was probably intended,
but "physical servers" is the better term.

In section 5 Summary, remove the following paragraph:

  DC services may vary, from infrastructure as a service (IaaS), to
  platform as a service (PaaS), to software as a service (SaaS).
  In these services, NVO3 networks are just a portion of such services.

as those *aaS terms occur nowhere else in the draft, and hence this text
doesn't summarize any prior material.

Thanks, --David

[Ballot comment]
Comments from Ralph Droms' Gen-ART review are worth looking at (if not already):

----

Summary: This draft is ready for publication as an Informational RFC.

Major issues: None

Minor issues: None

Nits/editorial comments:

I found several acronyms that did not have expansions.  I recommend a pass over the document for unexpanded acronyms..

Section 2: What is "broadcast/unknown" traffic (spec. "unknown"?); please expand the acronym "BUM".
  The paragraph that begins with "One NVO3 network [...]" is indented differently from the rest of the text.  Intentional or a typo?

Section 3.2: An illustrating figure for the use case described in this section would be helpful.
  Expand acronyms "PE" and "ABSR".
  I found the text using "Option A" and "Option B" confusing.  Exactly what are those options?

Section 5: I didn't understand the references to IaaS, PaaS and SaaS in the summary - there are no references to those services in the body of the document, or back pointers from the summary to relevant preceding text.

[Ballot comment]
I strongly agree with Alvaro that there is not much value in publishing this document independently. e.g. I do not see why this use case content cannot be included as a part of the NVO3 architecture (draft-ietf-nvo3-arch) draft if it needs to be published at all. One of the main issues that I have is that it is not clear who the audience of this document is (other than the WG in its initial stages).

[Ballot comment]

The security considerations text is pretty trite and not very
useful. The secdir review [1] makes some good points that
ought be reflected in the draft. An author seems to agree to
that's probably fine.

In addition as a use-cases draft, the use-case of hiring a VM
in order to attack other VMs in the DC ought be at least
mentioned, and there has been substantial work on such attacks,
e.g., [2] is a new instance of such and [3] has links to many
published papers.

Presumably NVO3 intends to at least consider such attacks and
that probably warrants a mention here or else we risk building
new networks that are highly vulnerable to other VMs in the
DC. (Whether or not such consideration leads to changes in
NVO3 protocols is an open question for me, but I do hope that
the WG consider the issues and that the IESG check that that
has happened at the relevant time.)

[1] https://www.ietf.org/mail-archive/web/secdir/current/msg07055.html
[2] https://media.ccc.de/v/33c3-8044-what_could_possibly_go_wrong_with_insert_x86_instruction_here
[3] https://scholar.google.com/scholar?as_ylo=2013&q=virtual+machine+cache+side+covert+channel+&hl=en&as_sdt=0,5

[Ballot comment]
I think that the publication value of this document has been taken over by events, mainly the fact that the nvo3 WG has been active for several years.  I am not standing in the way of publication, but I am ABSTAINing.

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

The IANA Services Operator has reviewed draft-ietf-nvo3-use-case-14.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: nvo3@ietf.org, draft-ietf-nvo3-use-case@ietf.org, akatlas@gmail.com, matthew.bocci@nokia.com, "Matthew Bocci" , nvo3-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: EXTENSION OF Last Call:  (Use Cases for Data Center Network Virtualization Overlay Networks) to Informational RFC


The IESG has received a request from the Network Virtualization Overlays
WG (nvo3) to consider the following document:
- 'Use Cases for Data Center Network Virtualization Overlay Networks'
  as Informational RFC

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 2017-01-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes data center network virtualization overlay
  (NVO3) network use cases that can be deployed in various data
  centers and serve different data center applications.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nvo3-use-case/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-nvo3-use-case/ballot/


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

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: nvo3@ietf.org, draft-ietf-nvo3-use-case@ietf.org, akatlas@gmail.com, matthew.bocci@nokia.com, "Matthew Bocci" , nvo3-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Use Cases for Data Center Network Virtualization Overlay Networks) to Informational RFC


The IESG has received a request from the Network Virtualization Overlays
WG (nvo3) to consider the following document:
- 'Use Cases for Data Center Network Virtualization Overlay Networks'
  as Informational RFC

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 2017-01-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes data center network virtualization overlay
  (NVO3) network use cases that can be deployed in various data
  centers and serve different data center applications.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nvo3-use-case/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-nvo3-use-case/ballot/


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

draft-ietf-nvo3-use-case-14.txt

Document Shepherd Write-Up

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

  Informational.
 
  This is appropriate as the draft describes a set of use cases forming the
  drivers for and scoping the work in NVO3. It does not specify new protocols,
  protocol numbers/registries, or protocol rules. Rather, it provides a descriptive
  foundation helping to scope the architecture for data center VPNs.

  The intended status is properly indicated.

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

Technical Summary

    This document describes data center network virtualization overly
        (NVO3) network use cases that can be deployed in various data
        centers and serve different data center applications.

Working Group Summary

  The document is one of the base documents chartered for the NVO3 working group.
  The document was originally created following interest in the WG to define the
  specific NVO3 use cases to help scope the NVO3 architecture and requirements,
  and any required protocols

  There are no IPR declarations on the draft .

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed on the list over a
  number of years.

  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Alia Atlas (akatlas@gmail.com).

(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 reviewed v12 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 14.

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

  No concerns. The document has received adequate review. The document has
  been developed within the WG and reviewed over a
  period of a number of IETFs. It received a number of comments during WG last call.

(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 further review required.

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

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

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

  There are no IPR declarations on the draft.


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

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants. It received a
    number of comments and significant discussion in WG last call that
    were addressed by the authors. There were no objections during last call, and
    comments were constructive and supportive of moving the draft forward.
    Prior to the WG last call, a call for interest was conducted which also demonstrated
    consensus in the value of progressing the draft.
   

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

  None indicated.

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

      ID-Nits passes.


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

  There are no relevant formal review criteria.

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

  Yes. All references are explicitly identified as 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?

  No

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

  No. All references are informative.

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

  This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  There are no IANA actions.

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

  There are no IANA actions.

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

  There are no sections containing formal language that needs reviewing.