Pete Resnick comment

The comment is:

"6.3.4 - No discussion of wildcard in this section. Does there need to
be?"

Because 6.3.4 is the section about SecurityBlock, I guess that "wildcard"
refers to wildcard certificate.  It is not possible to define a wildcard
RELOAD certificate because neither the reload URI or the rfc822Name
supports a wildcard, but under the current rules, there is nothing that
prevents adding a dns: to the SAN or a wildcard to the subject.

So, to remove ambiguity, I added a sentence that mandates to only use the
SAN identities defined, and to use an empty subject (as RFC 5280 does).
Polina Goltsman's comment 1

Comment:

"1) sec. 6.3.2:
length field in Forwarding Header covers what exactly?  it is not
really clear whether the length field counts the whole message or in
case of fragmentation only the fragment size. When reading Sec 6.7 is
seems that the former is meant, but the definition could and should be
clearer. Similarly, sec. 6.7 should be clear about this, e.g.,
describing that all Forwarding Headers are identical for fragments of
the same message with exception of the fragment field."

- Added text in 6.3.2 and 6.7, but saying the opposite.
Polina Goltsman major 2

"2) sec. 7.4.1.1: replica number handling is unclear it is unclear how
replica numbers are incremented (e.g., per peer) and what receiving peers
should actually do with this number. Is it important to store the value or
would a boolean be sufficient so that the peer knows that it's a
replica?"

- Add text explaining that repliac number are allocated an interpreted
  by the topology plugin.
- Explained how CHORD-RELOAD interprets the replica numbers.
Merge pull request #215 from petithug/polina-goltsman-major-2

Polina Goltsman major 2
Merge pull request #181 from petithug/pete-resnick

Pete Resnick comment
Merge pull request #214 from petithug/polina-goltsman-major-1

Polina Goltsman's major 1