Michael Chen issue

Here the text:

Base draft section 5.5.1 second paragraph states:

  "As described in Section 5.1, an Attach may be routed to either a
   Node-ID or to a Resource-ID.  An Attach routed to a specific Node-ID
   will fail if that node is not reached."

The second sentence above invalidates section 9.5 bullet 2, which says

  "2.  JP SHOULD send an Attach request to the admitting peer (AP) for
       Node-ID n.  The "send_update" flag should be used to acquire the
       routing table for AP."

Since JP's Node-ID is not yet valid, AP should fail the request as
instructed by 5.5.1.

I believe this should be changed to (similar to how to discover
successor in later paragraph):

  "2.  JP SHOULD send an Attach request to the admitting peer (AP) for
       Resource-ID n+1.  The "send_update" flag should be used to
       acquire the routing table for AP."
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