Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)
draft-ietf-p2psip-self-tuning-15

[Ballot comment]
In 6.2:

  A peer MAY choose to maintain a fixed-size predecessor list with only
  three entries as specified in RELOAD base.  However, it is
  RECOMMENDED that a peer maintains ceiling(log2(N)) predecessors.

I see that this text is the subject of negotiations with Pete, so I don't want to belabor it too much, but it seems to me that the only reason a peer would choose to do this would be that it didn't support self-tuning, since it seems that supporting a short predecessor list would make the node vulnerable to failures that the longer list is intended to prevent. The motivation for allowing this behavior is thus unclear to me. It may be that it's explained adequately and I missed it, but if not it might help to explain it here.

This is really cool work, and I greatly enjoyed reading it.  Thanks for documenting it!

[Ballot comment]
In 6.2:

  A peer MAY choose to maintain a fixed-size predecessor list with only
  three entries as specified in RELOAD base.  However, it is
  RECOMMENDED that a peer maintains ceiling(log2(N)) predecessors.

I see that this text is the subject of negotiations with Pete, so I don't want to belabor it too much, but it seems to me that the only reason a peer would choose to do this would be that it didn't support self-tuning, since it seems that supporting a short predecessor list would make the node vulnerable to failures that the longer list is intended to prevent.  The motivation for allowing this behavior is thus unclear to me.  It may be that it's explained adequately and I missed it, but if not it might help to explain it here.

This is really cool work, and I greatly enjoyed reading it.  Thanks for documenting it!

[Ballot comment]
5.

Tilting at a windmill: The MUSTs in the section don't help the implementer:

s/MUST be used/is used
s/MUST maintain/maintains
s/MUST restart the time and carry out/restarts the timer and carries out

5.1

  Regardless of the type, all Update requests
  include an 'uptime' field.  Since the self-tuning extensions require
  information on the uptimes of peers in the routing table, the sender
  of an Update request MUST include its current uptime in seconds in
  the 'uptime' field.

I think in the newspaper business, this is called "burying the lede". The MUST is in the wrong place. What's important is that all Update requests MUST include an 'uptime' field. The MUST in the second sentence makes it confusing as to whether there are choices about other kinds of Updates or different format for time ("Are there other senders that don't have to use 'uptime'?" "Could they send minutes instead of seconds, and you can only use seconds in Updates? Is that why they're saying 'MUST'?" I suggest replacing with:

NEW
  The self-tuning extensions require information on the uptimes of
  peers in the routing table. The sender of an Update request includes
  its current uptime (in seconds) in the 'uptime' field. Regardless of
  the type, all Update requests MUST include an 'uptime' field.
END

Maybe I'm not understanding how this works, but the laste sentence of this section is confusing to me. Is the rule that if I've got enough space in my data structure for everything I got from my peer *and* what I had in there before, I keep everything? What if there's not enough space to keep everything? Do I trim what I had and add everything I got in the update, or do I trim what I got in the update?

5.2.

  Therefore, when the self-tuning
  mechanisms are used, each peer MUST send a periodic Update request
  only to its first predecessor and first successor on the Chord ring.
 
Again, potentially confusing because you've described the requirement backwards:

NEW
  Therefore, when the self-tuning mechanisms are used, each peer only
  sends a periodic Update request to its first predecessor and first
  successor on the Chord ring; it MUST NOT send Update requests to
  others.
END

In the last two paragraphs of this section, which of the MUSTs are actual requirements that an implementation needs to be aware of, and which are just statements of the way things are done in the protocol? In other words, why is the following not a reasonable replacement?

NEW
  The neighbor stabilization routine is executed when the
  stabilization timer fires.  To begin the neighbor stabilization
  routine, a peer sends an Update request to its first successor
  and its first predecessor.  The type of the Update request MUST be
  'neighbors'.  The Update request includes the successor and
  predecessor lists of the sender.  If a peer receiving such an Update
  request learns from the predecessor and successor lists included in
  the request that new peers can be included in its neighborhood set,
  it sends Attach requests to the new peers.

  After a new peer has been added to the predecessor or successor list,
  an Update request of type 'peer_ready' is sent to the new peer.
  This allows the new peer to insert the sender into its neighborhood
  set.
END

If the answer to the question, "Why does it say MUST?" is "Because if you don't do that, you're not doing the protocol", that's going to confuse implementers and can make for brittle code.

Please review 5.3, 5.4, 6.1, 6.3, 6.4, 6.5, 6.6 for similar uses.

6.2:

  The size of the successor list MUST be set to ceiling(log2(N)).  An
  implementation MAY place a lower limit on the size of the successor
  list.

MUST/MAY conflict. I think the first sentence should say "MUST be set to a maximum of".

In the last paragraph, change "MAY" to "can".

[Ballot comment]


Providing a way to estimate N seems like a fine improvement
over 6940. Good stuff.

- 5.6: What does a "better predecessor" mean here? Asking
because there's stuff you MUST do when you find one.

- 5.6: I also wondered if there's any security issue
associated with having a MUST there - could a leaving node
use that to force its successor to talk to nodes the leaving
node has chosen for some nefarious purpose? (Apologies, I
forget RELOAD, which may already counter that;-)

[Ballot comment]
Probably a very simple question from browsing through the doc (mainly due to my lack of RELOAD knowledge, combined with my laziness to review the 175 page RFC 6940)

  This document extends the mandatory-to-implement chord-reload
  algorithm by making it self-tuning.  The use of the self-tuning
  feature is optional.  However, when used, it needs to be supported by
  all peers in the RELOAD overlay network.

From an operational point of view, what is the mechanism to discover that all peers support this optional self-tuning feature?

[Ballot comment]
Thanks for producing this document. The static configuration seemed kind of lame when I was following RELOAD more closely - this seems like a much better idea!

[Ballot comment]
Thanks for addressing all my comments in version -13.  The one we're still talking about, now a non-blocking comment, is below:

1. In the Introduction:

  These
  characteristics are then used to configure the DHT in a static
  fashion by using fixed values for parameters such as the size of the
  successor set, size of the routing table, and rate of maintenance
  messages.  The problem with this approach is that it is not possible
  to achieve a low failure rate and a low communication overhead by
  using fixed parameters.  Instead, a better approach is to allow the
  system to take into account the evolution of network conditions and
  adapt to them.  This document extends the mandatory-to-implement
  chord-reload algorithm by making it self-tuning.  Two main advantages
  of self-tuning are that users no longer need to tune every DHT
  parameter correctly for a given operating environment and that the
  system adapts to changing operating conditions.

Does this mean that this self-tuning version is intended to be the way chord-reload is implemented in the future?  Or is it just meant to be an optional feature, which might or might not be implemented for chord-reload?  It seems that self-tuning doesn't work unless most peers support it and share the necessary information.

Reply from Jouni:
" The self-tuning version is an optional feature. But it needs to be supported by all the peers in the overlay. A RELOAD overlay can either choose to use chord-reload or the self-tuning version."

As a non-blocking comment, would it be useful to say what you just told me as part of the text I quote above?  I suggest this, which you may accept or decline as you see best (it also inserts a paragraph break for the long paragraph):

NEW
  These
  characteristics are then used to configure the DHT in a static
  fashion by using fixed values for parameters such as the size of the
  successor set, size of the routing table, and rate of maintenance
  messages.  The problem with this approach is that it is not possible
  to achieve a low failure rate and a low communication overhead by
  using fixed parameters.  Instead, a better approach is to allow the
  system to take into account the evolution of network conditions and
  adapt to them.

  This document extends the mandatory-to-implement chord-reload
  algorithm by making it self-tuning.  The self-tuning feature is
  optional. When it is used, it needs to be supported by all peers in
  the overlay.  Two main advantages of self-tuning are that users no
  longer need to tune every DHT parameter correctly for a given
  operating environment and that the system adapts to changing
  operating conditions.
END

[Ballot comment]
Thanks for addressing all my comments in version -13.  The one we're still talking about, now a non-blocking comment, is below:

1. In the Introduction:

  These
  characteristics are then used to configure the DHT in a static
  fashion by using fixed values for parameters such as the size of the
  successor set, size of the routing table, and rate of maintenance
  messages.  The problem with this approach is that it is not possible
  to achieve a low failure rate and a low communication overhead by
  using fixed parameters.  Instead, a better approach is to allow the
  system to take into account the evolution of network conditions and
  adapt to them.  This document extends the mandatory-to-implement
  chord-reload algorithm by making it self-tuning.  Two main advantages
  of self-tuning are that users no longer need to tune every DHT
  parameter correctly for a given operating environment and that the
  system adapts to changing operating conditions.

Does this mean that this self-tuning version is intended to be the way chord-reload is implemented in the future?  Or is it just meant to be an optional feature, which might or might not be implemented for chord-reload?  It seems that self-tuning doesn't work unless most peers support it and share the necessary information.

Reply from Jouni:
" The self-tuning version is an optional feature. But it needs to be supported by all the peers in the overlay. A RELOAD overlay can either choose to use chord-reload or the self-tuning version."

As a non-blocking comment, would it be useful to say what you just told me as part of the text I quote above?  I suggest this, which you may accept or decline as you see best (it also inserts a paragraph break for the long paragraph):

NEW
  These
  characteristics are then used to configure the DHT in a static
  fashion by using fixed values for parameters such as the size of the
  successor set, size of the routing table, and rate of maintenance
  messages.  The problem with this approach is that it is not possible
  to achieve a low failure rate and a low communication overhead by
  using fixed parameters.  Instead, a better approach is to allow the
  system to take into account the evolution of network conditions and
  adapt to them.

  This document extends the mandatory-to-implement chord-reload
  algorithm by making it self-tuning.  The self-tuning feature is optional.
  When it is used, it needs to be supported by all peers in the overlay.
  Two main advantages of self-tuning are that users no longer need
  to tune every DHT parameter correctly for a given operating
  environment and that the system adapts to changing operating
  conditions.
END

[Ballot discuss]
Quick discussion on two things, please:

1. In the Introduction:

  These
  characteristics are then used to configure the DHT in a static
  fashion by using fixed values for parameters such as the size of the
  successor set, size of the routing table, and rate of maintenance
  messages.  The problem with this approach is that it is not possible
  to achieve a low failure rate and a low communication overhead by
  using fixed parameters.  Instead, a better approach is to allow the
  system to take into account the evolution of network conditions and
  adapt to them.  This document extends the mandatory-to-implement
  chord-reload algorithm by making it self-tuning.  Two main advantages
  of self-tuning are that users no longer need to tune every DHT
  parameter correctly for a given operating environment and that the
  system adapts to changing operating conditions.

Does this mean that this self-tuning version is intended to be the way chord-reload is implemented in the future?  Or is it just meant to be an optional feature, which might or might not be implemented for chord-reload?  It seems that self-tuning doesn't work unless most peers support it and share the necessary information.

In Section 2, Terminology:

  This document uses the terminology and definitions from the Concepts
  and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts]
  draft.

If that document is needed for terminology and definitions, doesn't that make it a normative reference?

[Ballot comment]
And a few non-blocking comments on minor things:

1. In Section 4, I found "ith" to be distracting -- I kept reading it as "with" without the "w", and had to force myself to think "eye-th".  I don't know what to do about it, and suggest leaving it for the RFC Editor to come up with something (maybe they've been there before and already have an answer).  But I just wanted to bring it up.

2. In the last sentence of Section 6.3, "Use of this approach is RECOMMENDED.": What does "this approach" refer to?  It looks like it refers to setting K to 25% of the routing table size.  If so, I think "Use of that value is RECOMMENDED," would be clearer.

Or is it the technique described in the whole section, which begins "A typical approach is..."?  In that case, I suggest either (1) putting that final sentence into a paragraph of its own or (2) putting that into the first sentence of the section, as "A typical approach, and the one that is RECOMMENDED, is...".

3. In the IANA Considerations: The authors have sorted this out with IANA, but I think clarifying the text is the best thing to do anyway:

OLD
  This document registers one new URI for the self-tuning namespace in
  the IETF XML registry defined in [RFC3688].
NEW
  This document registers one new URI for the self-tuning namespace in
  the "ns" subregistry of the IETF XML registry defined in [RFC3688].
END

While we're there, I don't think that 3688 is a normative reference -- I think it's informative.  But do as you see fit there.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-p2psip-self-tuning-11.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

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

In the RELOAD Extensions Registry within the REsource LOcation And Discovery (RELOAD) registry located at:

http://www.iana.org/assignments/reload/

a new extension is to be added to the registry as follows:

Code: 0x3
Extension Name: self_tuning_data
Reference: [ RFC-to-be ]

IANA understands this to be 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)) to Proposed Standard


The IESG has received a request from the Peer-to-Peer Session Initiation
Protocol WG (p2psip) to consider the following document:
- 'Self-tuning Distributed Hash Table (DHT) for REsource LOcation And
  Discovery (RELOAD)'
  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 2014-06-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


  REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P)
  signaling protocol that provides an overlay network service.  Peers
  in a RELOAD overlay network collectively run an overlay algorithm to
  organize the overlay, and to store and retrieve data.  This document
  describes how the default topology plugin of RELOAD can be extended
  to support self-tuning, that is, to adapt to changing operating
  conditions such as churn and network size.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-p2psip-self-tuning/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-p2psip-self-tuning/ballot/


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

Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery
(RELOAD) (draft-ietf-p2psip-self-tuning-11)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?

Proposed Standard

Why is this the proper type of RFC?

The document has received significant community review, and appears to enjoy
enough community interest to be considered valuable. It defines extensions to
RFC6940, which also has the status of Proposed Standard.

Is this type of RFC indicated in the title page header?

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:

Peers in a RELOAD overlay network collectively run an overlay algorithm to
organize the overlay, and to store and retrieve data. This document describes
an extension to the default topology plugin of RELOAD to support self-tuning,
meaning to make it capable of adapting to changing operating conditions such as
churn and network size.

Working Group Summary:

The normal WG process was followed and the document has been discussed for
several years. The document as it is now, reflects WG consensus, with nothing
special worth noting.

Document Quality:

The document was thoroughly reviewed by Marc Petit-Huguenin and Carlos J.
Bernardos.

Personnel:

Who is the Document Shepherd?

Carlos J. Bernardos

Who is the Responsible Area Director?

Alissa Cooper

(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 personally done a thorough review of the document.
Some changes (mainly editorial) were requested to the authors and included in
the last revision of the draft. The Document Shepherd believes the document is
ready for forwarding to IESG for publication.

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

The Document Shepherd has no concerns about the depth or breadth of these
reviews.

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

A review of the Section 7 was requested to the APPS area. Martin J. Dürst
was selected and performed a review of the whole document.

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

The Document Shepherd has no 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?

Yes.

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

No.

(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 is WG consensus behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.

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

There are no nits.

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

The document meets the review criteria.

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

Yes.

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

No.

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

No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

No.

(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 document introduces one additional extension to the "RELOAD Extensions"
Registry. This registry is described in [I-D.ietf-p2psip-base].

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

None.

(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 formal language segments exist.

Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery
(RELOAD) (draft-ietf-p2psip-self-tuning-11)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?

Proposed Standard

Why is this the proper type of RFC?

The document has received significant community review, and appears to enjoy
enough community interest to be considered valuable. It defines extensions to
draft-ietf-p2psip-base, which also has an intended status of Proposed Standard.

Is this type of RFC indicated in the title page header?

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:

Peers in a RELOAD overlay network collectively run an overlay algorithm to
organize the overlay, and to store and retrieve data. This document describes
an extension to the default topology plugin of RELOAD to support self-tuning,
meaning to make it capable of adapting to changing operating conditions such as
churn and network size.

Working Group Summary:

The normal WG process was followed and the document has been discussed for
several years. The document as it is now, reflects WG consensus, with nothing
special worth noting.

Document Quality:

The document was thoroughly reviewed by Marc Petit-Huguenin and Carlos J.
Bernardos.

Personnel:

Who is the Document Shepherd?

Carlos J. Bernardos

Who is the Responsible Area Director?

Alissa Cooper

(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 personally done a thorough review of the document.
Some changes (mainly editorial) were requested to the authors and included in
the last revision of the draft. The Document Shepherd believes the document is
ready for forwarding to IESG for publication.

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

The Document Shepherd has no concerns about the depth or breadth of these
reviews.

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

A review of the Section 7 was requested to the APPS area. Martin J. Dürst
was selected and performed a review of the whole document.

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

The Document Shepherd has no 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?

Yes.

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

No.

(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 is WG consensus behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.

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

There are no nits.

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

The document meets the review criteria.

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

Yes.

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

No.

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

No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

No.

(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 document introduces one additional extension to the "RELOAD Extensions"
Registry. This registry is described in [I-D.ietf-p2psip-base].

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

None.

(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 formal language segments exist.