Mary Marnes's comment 1

The comment is:

"- [-17, section 10.5] Section 11.5, 3rd para:  text uses the phrase
"it can note the Node-ID in the response and use this Node-ID to start
sending requests".  It's not clear whether the use of the Node-ID is a
MAY or a MUST.    [Note: Marc's response to this was that it's an open
issue, but this should be clarified prior to publication]."

- I changed the text to use MUST.
- I also changed the previous paragraph to say that the Resource-ID is
  used as destination instaed of the Node-ID.
- Nit in next section: s/resource ID/Resource-ID/
Mary Barnes' comment 2

The text of the comment is:

"- [-17] Section 1.2.1, 2nd paragraph: I don't understand the example
as to why a single application requires multiple usages - i.e, why
voicemail?  Isn't the intent to say that an application might need to
use both SIP and XMPP - i.e., you wouldn't define a "usage" for an
application, would you?
[While Cullen responded to this comment with an explanation, there was
no change to clarify the text and Marc's response didn't help clarify
my concern]"

Cullen's response was:

"storing voicemail in the DHT would require a different usage than the
type of rendezvous service of XMPP or SIP"

- Text modified by reusing Cullent's response.
Mary Barnes's comment 3

The comment is:

"- Section 3.3, 2nd paragraph after the capability bullet list, next to
last sentence.  There is at least an article missing from this
sentence and it reads rather awkwardly. Perhaps changing to something
like:
OLD:
   If there is a failure on
   the reverse path caused by topology change since the request was
   sent, this will be handled by the end-to-end retransmission of the
   response as described in Section 6.2.1.
NEW:
   Note that a failure on
   the reverse path caused by a topology change after the request was
   sent, will be handled by the end-to-end retransmission of the
   response as described in Section 6.2.1."

- Change as suggested, but without the comma.
Mary Barnes's comment 4

The text of the comment is:

"- [-17] Section 3.3, last paragraph.  Add a reference to 5.4.2.4
after "RouteQuery method""

- Change as suggested (section is 5.4.2.4).
Mary Barnes' comment 5

The text of the comment is:

"- Section 3.4, last paragraph, 3rd sentence: "that the specified by
the algorithm" should be something like "than specified by the
algorithm"."

- Change as suggested.
Mary Barnes' comment 6

The text of the comment is:

"- [-23] Section 6.6:  All my previous concerns were addressed, except,
the Note to implementors paragraph still seems out of context - it
should be deleted or this section should be restructured so it is in
context."

- Complete rewite.  Note the additional MUST for Overlay Link protocols.
Mary Barnes's comment 7

The text of the comment is:

"- [-17, section 11] Section 12, Second paragraph, 3rd sentence
says that "It gets routed to the admitting peer (AP), yet the flow
shows that the message first gets routed to the PP and then onto AP.
It would be helpful if that were clarified.   [Note: Marc's response
indicated that he thought this was fixed in the -23, however, the diff
shows no changes to that specific text between the -17 and the -24 ]"

- No reason to route through PP, so flow updated to reflect the text.
Merge pull request #184 from petithug/michael-chen

Michael Chen issue
Merge pull request #185 from petithug/mary-barnes-1

Mary Marnes's comment 1
Merge pull request #186 from petithug/mary-barnes-2

Mary Barnes' comment 2
slight edit to voicemail text
update date
Merge pull request #187 from petithug/mary-barnes-3

Mary Barnes's comment 3
Merge pull request #188 from petithug/mary-barnes-4

Mary Barnes's comment 4
Merge pull request #189 from petithug/mary-barnes-5

Mary Barnes' comment 5
Merge pull request #190 from petithug/mary-barnes-6

Mary Barnes' comment 6
Merge pull request #191 from petithug/mary-barnes-7

Mary Barnes's comment 7
Mary Barnes' nits

Text is:

"- Section 1.2.5, 2nd para, last sentence: this sentence is a bit tough
to interpret on a first read.  I would suggest rewording something
like the following:
OLD:
  This layer is to the Message Transport Layer as link-
   level congestion control and retransmission in modern wireless
   networks is to Internet transport protocols.
NEW:
   The relation of this layer to the Message Transport Layer
   "is similar to"|"can be likened to" the relation of the link-
   level congestion control and retransmission in modern wireless
   networks to Internet transport protocols.

- Section 3.4, last paragraph, 4th sentence: "in accord" -> "in
  accordance"

- Section 10.1, 2nd paragraph, 5th sentence: "can be thought of a
doubly-linked list" -> "can be thought of as a doubly-linked list"

- Section 15, last paragraph: "help resolve" -> "helped resolve""

- Text modified as suggested.
Merge pull request #192 from petithug/mary-barnes-nits

Mary Barnes' nits
Roland Bless' comment 1

Text is:

""1.  JP MUST connect to its chosen bootstrap node."
it is unclear what "connect" exactly means. This is actually
described in Sec. 11.5:
  "When contacting a bootstrap node, the joining node MUST first form
   the DTLS or TLS connection to the bootstrap node and then sends an
   Attach request over this connection with the destination Node-ID set
   to the joining node's Node-ID."
So my suggestion is to explain it a little but more or to put a forward
reference to section 11.5."

- Add reference to section 11.4.