REsource LOcation And Discovery (RELOAD) Base Protocol
RFC 6940

[Ballot discuss]

  The Gen-ART Review by Mary Barnes on 19-Feb-2013 raised one concern
  that needs to be sorted out before this document is approved.  Please
  consider the other comments in that review.

  In Section 11.5, 3rd para, the document says: "it can note the Node-ID
  in the response and use this Node-ID to start sending requests".  Is
  the use of the Node-ID MAY or a MUST?

[Ballot comment]
Note: Gonzalo didn't reset the ballot, so I am assuming that there's no need to do a full re-review. So I checked on my comments that I had in earlier. Only two outstanding:

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

6.5 - Not clear to me why this document settles on ICE (or anything lower layer). Seems like it could have been abstracted out and left to a different layer. I'm kind of disappointed that all of section 6.5 (and maybe sections 6.6 and 9) is not a separate document. (I understand that this is the WG wanted to do it. Just registering my complaint, but I won't make a fuss.)

IESG/Authors/WG Chairs:

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

We understand that, upon approval of this document seventeen actions are required to be completed by IANA.

First, in the well-known URI registry located at:

http://www.iana.org/assignments/well-known-uris/well-known-uris.xml

a new URI suffix is to be registered as follows:

URI suffix: reload-config
Change Controller: IETF
Reference: [ RFC-to-be ]
Related information: [ none ]

Second, in the Service Name and transport protocol Port Number Registry located at:

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

the registration data for port number 6084 will be changed.  The changes are as follows:

Registration Technical Contact: Cullen Jennings
Registration Owner: IETF
Transport Protocol: TCP & UDP 
Port Number: 6084
Service Name: reload-config
Description: Peer to Peer Infrastructure Configuration

NOTE: We have initiated a request and sent this to the Port expert for review.

Third, we will create a new registry called the "RELOAD Overlay Algorithm Type" registry. Entries in this registry are strings.

The registration policy for this registry is IETF Review as defined in RFC 5226. 

The initial contents of this registry are:

Algorithm Name        Reference
---------------------- --------------
CHORD-RELOAD          [ RFC-to-be ]
EXP-OVERLAY            [ RFC-to-be ]

Fourth, we will create a new registry called the "RELOAD Access Control Policy" registry.  Entries in this registry are strings.

The registration policy for this new registry will be Standards Action as defined by RFC 5226.

The initial contents of this registry are:

Access Policy          Reference
---------------------- ---------------
USER-MATCH            [ RFC-to-be ]
NODE-MATCH            [ RFC-to-be ]
USER-NODE-MATCH      [ RFC-to-be ]
NODE-MULTIPLE        [ RFC-to-be ]
EXP-MATCH            [ RFC-to-be ]

Fifth, we will create a new registry called the "RELOAD Application-ID" registry.  Entries in this registry are 16-bit integers.

Application-IDs in the range 0x0001 to 0x7fff will be registered via Standards Action as defined in RFC 5226.  Application-IDs in the range 0x8000 to 0xf000 will be registered through Expert Review as defined in RFC 5226.  Application-IDs in the range 0xf001 to 0xfffe are reserved for private use. 

The initial contents of this registry are:

Application            Application-ID              Reference
---------------------- --------------------------  ---------------
INVALID                                        0  [ RFC-to-be ]
SIP                                          5060  Reserved for use
                                                  by SIP Usage
SIP                                          5061  Reserved for use
                                                  by SIP Usage
Reserved                                  0xffff  [ RFC-to-be ]

Sixth, we will create a new registry called the "RELOAD Data Kind-ID" registry.  Entries in this registry are 32-bit integers.

Data Kind-IDs in the range 0x00000001 to 0x7fffffff will be registered via Standards Action as defined in RFC 5226.  Data Kind-IDs in the range 0x8000000 to 0xf0000000 will be registered through Expert Review as defined in RFC 5226. Data Kind-IDs in the range 0xf0000001 to 0xfffffffe are reserved for private use via the Kind description mechanism described in Section 11 of [ RFC-to-be ]. 

The initial contents of this registry are:

Kind                    Kind-ID                Reference
----------------------- ----------------------- ----------------
INVALID                                      0 [ RFC-to-be ]
TURN-SERVICE                                  2 [ RFC-to-be ]
CERTIFICATE_BY_NODE                          3 [ RFC-to-be ]
CERTIFICATE_BY_USER                          16 [ RFC-to-be ]
Reserved                            0x7fffffff [ RFC-to-be ]
Reserved                            0xfffffffe [ RFC-to-be ]

Seventh, we will create a new registry called the "RELOAD Data Model" registry.  Entries in this registry are strings.

RELOAD Data Models will be registered via Standards Action as defined in RFC 5226.

The initial contents of this registry are:

Data Model                    Reference
----------------------------- ------------------
INVALID                      [ RFC-to-be ]
SINGLE                        [ RFC-to-be ]
ARRAY                        [ RFC-to-be ]
DICTIONARY                    [ RFC-to-be ]
EXP-DATA                      [ RFC-to-be ]
RESERVED                      [ RFC-to-be ]

Eighth, we will create a new registry called the "RELOAD Message Code" registry.  Entries in this registry are 16-bit integers.

RELOAD Message Codes will be registered via Standards Action as defined in RFC 5226.

The initial contents of this registry are:

      +---------------------------------+----------------+---------------+
      | Message Code Name              |    Code Value |    Reference |
      +---------------------------------+----------------+---------------+
      | invalidMessageCode              |              0 | [ RFC-to-be ] |
      | probe_req                      |              1 | [ RFC-to-be ] |
      | probe_ans                      |              2 | [ RFC-to-be ] |
      | attach_req                      |              3 | [ RFC-to-be ] |
      | attach_ans                      |              4 | [ RFC-to-be ] |
      | unused                          |              5 |              |
      | unused                          |              6 |              |
      | store_req                      |              7 | [ RFC-to-be ] |
      | store_ans                      |              8 | [ RFC-to-be ] |
      | fetch_req                      |              9 | [ RFC-to-be ] |
      | fetch_ans                      |            10 | [ RFC-to-be ] |
      | unused (was remove_req)        |            11 | [ RFC-to-be ] |
      | unused (was remove_ans)        |            12 | [ RFC-to-be ] |
      | find_req                        |            13 | [ RFC-to-be ] |
      | find_ans                        |            14 | [ RFC-to-be ] |
      | join_req                        |            15 | [ RFC-to-be ] |
      | join_ans                        |            16 | [ RFC-to-be ] |
      | leave_req                      |            17 | [ RFC-to-be ] |
      | leave_ans                      |            18 | [ RFC-to-be ] |
      | update_req                      |            19 | [ RFC-to-be ] |
      | update_ans                      |            20 | [ RFC-to-be ] |
      | route_query_req                |            21 | [ RFC-to-be ] |
      | route_query_ans                |            22 | [ RFC-to-be ] |
      | ping_req                        |            23 | [ RFC-to-be ] |
      | ping_ans                        |            24 | [ RFC-to-be ] |
      | stat_req                        |            25 | [ RFC-to-be ] |
      | stat_ans                        |            26 | [ RFC-to-be ] |
      | unused (was attachlite_req)    |            27 | [ RFC-to-be ] |
      | unused (was attachlite_ans)    |            28 | [ RFC-to-be ] |
      | app_attach_req                  |            29 | [ RFC-to-be ] |
      | app_attach_ans                  |            30 | [ RFC-to-be ] |
      | unused (was app_attachlite_req) |            31 | [ RFC-to-be ] |
      | unused (was app_attachlite_ans) |            32 | [ RFC-to-be ] |
      | config_update_req              |            33 | [ RFC-to-be ] |
      | config_update_ans              |            34 | [ RFC-to-be ] |
      | exp_a_req                      |            35 | [ RFC-to-be ] |
      | exp_a_ans                      |            36 | [ RFC-to-be ] |
      | exp_b_req                      |            37 | [ RFC-to-be ] |
      | exp_b_ans                      |            38 | [ RFC-to-be ] |
      | reserved                        | 0x8000..0xfffe | [ RFC-to-be ] |
      | error                          |        0xffff | [ RFC-to-be ] |
      +---------------------------------+----------------+---------------+

Ninth, we will create a new registry called the "RELOAD Error Code" registry.  Entries in this registry are 16-bit integers.

RELOAD Error Codes will be registered via Standards Action as defined in RFC 5226.

The initial contents of this registry are:

    +-------------------------------------+----------------+---------------+
    | Error Code Name                    |    Code Value |  Reference  |
    +-------------------------------------+----------------+---------------+
    | invalidErrorCode                    |              0 | [ RFC-to-be ] |
    | Unused                              |              1 | [ RFC-to-be ] |
    | Error_Forbidden                    |              2 | [ RFC-to-be ] |
    | Error_Not_Found                    |              3 | [ RFC-to-be ] |
    | Error_Request_Timeout              |              4 | [ RFC-to-be ] |
    | Error_Generation_Counter_Too_Low    |              5 | [ RFC-to-be ] |
    | Error_Incompatible_with_Overlay    |              6 | [ RFC-to-be ] |
    | Error_Unsupported_Forwarding_Option |              7 | [ RFC-to-be ] |
    | Error_Data_Too_Large                |              8 | [ RFC-to-be ] |
    | Error_Data_Too_Old                  |              9 | [ RFC-to-be ] |
    | Error_TTL_Exceeded                  |            10 | [ RFC-to-be ] |
    | Error_Message_Too_Large            |            11 | [ RFC-to-be ] |
    | Error_Unknown_Kind                  |            12 | [ RFC-to-be ] |
    | Error_Unknown_Extension            |            13 | [ RFC-to-be ] |
    | Error_Response_Too_Large            |            14 | [ RFC-to-be ] |
    | Error_Config_Too_Old                |            15 | [ RFC-to-be ] |
    | Error_Config_Too_New                |            16 | [ RFC-to-be ] |
    | Error_In_Progress                  |            17 | [ RFC-to-be ] |
    | Error_Exp_A                        |            18 | [ RFC-to-be ] |
    | Error_Exp_B                        |            19 | [ RFC-to-be ] |
    | Error_Invalid_Message              |            20 | [ RFC-to-be ] |
    | reserved                            | 0x8000..0xfffe | [ RFC-to-be ] |
    +-------------------------------------+----------------+---------------+

Tenth, we will create a new registry called the "RELOAD Overlay Link registry". 

RELOAD Overlay Links will be registered via Standards Action as defined in RFC 5226.

The initial contents of this registry are:

Protocol              Code          Reference
--------------------  -----        --------------------
INVALID-PROTOCOL          0        [ RFC-to-be ]
DTLS-UDP-SR              1        [ RFC-to-be ]
DTLS-UDP-SR-NO-ICE        3        [ RFC-to-be ]
TLS-TCP-FH-NO-ICE        4        [ RFC-to-be ]
EXP-LINK                  5        [ RFC-to-be ]
reserved                255        [ RFC-to-be ]

Eleventh, we will create a new registry called the "Overlay Link Protocol Registry".  Entries in this new registry are strings.

Overlay Link Protocols will be registered via Standards Action as defined in RFC 5226.

The initial contents of this registry are:

Link Protocol            Reference
----------------------    --------------------
TLS                      [ RFC-to-be ]
EXP-PROTOCOL              [ RFC-to-be ]

Twelfth, we will create a new registry called the "Forwarding Option Registry"  Entires in this new registry are 8-bit integers.

Forwarding Options between 1 and 127 will be registered via Standards Action as defined in RFC 5226.  Engtries between 128 and 254 will be registered bia Specification Required as defined in RFC 5226. 

The initial contents of this registry are:

Forwarding Option        Code  Reference
------------------------- -----  --------------
invalidForwardingOption      0  [ RFC-to-be ]
exp-forward                  1  [ RFC-to-be ]
reserved                    255  [ RFC-to-be ]

Thirteenth, we will create a new registry called the "RELOAD Probe Information Type Registry".  Entries in this new registry are 8-bit integers.

Probe Information Types will be registered via Standards Action as defined in RFC 5226.

The initial contents of this registry are:

Probe Option:        Code  Reference
---------------      ----  --------------
invalidProbeOption      0  [ RFC-to-be ]
responsible_set        1  [ RFC-to-be ]
num_resources          2  [ RFC-to-be ]
uptime                  3  [ RFC-to-be ]
exp-probe              4  [ RFC-to-be ]
reserved              255  [ RFC-to-be ]

Fourteenth, we will create a new registry called the "RELOAD Extensions Registry".  Entries in this registry are 8-bit integers.

RELOAD Extensions will be registered via Specification Required as defined in RFC 5226.

The initial contents of this registry are:

Extensions Name:              Code      Reference
----------------------------- --------  --------------
invalidMessageExtensionType          0  [ RFC-to-be ]
exp-ext                              1  [ RFC-to-be ]
reserved                        0xFFFF  [ RFC-to-be ]

Fifteenth, in the Permanent URI scheme registry located at:

http://www.iana.org/assignments/uri-schemes.html

a new URI Scheme will be registered as follows:

URI Scheme: reload
Description: RELOAD Protocol
reference: [ RFC-to-be ]

Sixteenth, in the applicaton media type registry located at:

http://www.iana.org/assignments/media-types/application

a new media type will be registered as follows:

p2p-overlay+xml
Reference: [ RFC-to-be ]

Seventeenth, in the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

two new NS entires will be created as follows:

ID: config-base
URI: urn:ietf:params:xml:ns:p2p:config-base
Registration template: N/A, the requested URIs are XML namespaces
Reference: [ RFC-to-be ]

ID: config-chord
URI: urn:ietf:params:xml:ns:p2p:config-chord
Registration template: N/A, the requested URIs are XML namespaces
Reference: [ RFC-to-be ]

We understand that these seventeen actions are the only ones that need 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.

[Ballot comment]

Thanks again for handling my gigantic discuss/comments last
time around.

I had a (not so quick:-) check of the diffs between -18 and
-24 and all seems well, but I do have one question: is the
overlay-reliability-timer in the configuration defined in 11.1
supposed to override the "15 second" timer ("Maximum Request
Lifetime") defined in section 2 and and used in various
places, if the value of the overlay-reliability-timer is more
than 15000?

If so, then it might be worth yet another pass over this to
check that all the hard-coded time values (and there are a few
in both seconds and ms) are in whack with that configuration
element.

If not, then it might be worth saying that these are different
and how, in 11.1 and/or section 2.

Or, maybe I didn't read enough and that's a dumb question, in
which case, sorry about that.

And lastly, since I do DTN stuff now and then I'm really
curious as to what might happen if I wanted to set the
overlay-reliability-timer to 86400000 (one day). But I don't
expect you to give an answer or do anything about that:-)

[Ballot discuss]
I haven't finished my review, but I wanted
to post this issue early to give the
document shepherd time to fix the problem
before the IESG telechat.  I'll clear this Discuss
and post any new issues as soon as I
finish my review.

The IESG writeup appears to be out
of date and should be revised to reflect
the recent history and current state of
the document.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (REsource LOcation And Discovery (RELOAD) Base Protocol) to Proposed Standard


The IESG has received a request from the Peer-to-Peer Session Initiation
Protocol WG (p2psip) to consider the following document:
- 'REsource LOcation And Discovery (RELOAD) Base Protocol'
  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 2013-02-19. 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.

Note that this is the second IETF LC on this draft. The document was revised in response to comments made during its IESG review. There were no real semantic or functional changes -- just clarifications in the wording, adding of references, and making word use and capitalization more consistent throughout the document.

Abstract


  This specification defines REsource LOcation And Discovery (RELOAD),
  a peer-to-peer (P2P) signaling protocol for use on the Internet.  A
  P2P signaling protocol provides its clients with an abstract storage
  and messaging service between a set of cooperating peers that form
  the overlay network.  RELOAD is designed to support a P2P Session
  Initiation Protocol (P2PSIP) network, but can be utilized by other
  applications with similar requirements by defining new usages that
  specify the kinds of data that needs to be stored for a particular
  application.  RELOAD defines a security model based on a certificate
  enrollment service that provides unique identities.  NAT traversal is
  a fundamental service of the protocol.  RELOAD also allows access
  from "client" nodes that do not need to route traffic or store data
  for others.




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

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


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1191/

[Ballot comment]
This is a well written document, and is much improved over the last version that I read. I thank the editors for the work that they have done.

I understand that the example using port "6100" is an error and will be corrected in the next version to the assigned port.

I am therefore clearing with the request that the shepherding AD verifies this change.

[Ballot discuss]
This is a well written document, and is much improved over the last version that I read.
I would like to thank the authors.

I do have one last question for the authors and one for my colleagues on the IESG. Hopefully this will be a simple matter to clear up.

Authors:

In the text

As an example, here is the wire representation of the IPv4 address "192.0.2.1" with port "6100".

I assume that port is a UDP/TCP. I looked at the port registry and saw that 6100 was assigned to  synchronet-db, but I did not see that protocol discussed in the draft. Please can you clarify:

1) Are you referring to a UDP/TCP port here? If so,
2) Is 6100 a real protocol you are recommending or an example port number

IESG:

I know the policy on example IP address, but is there a similar policy on example port numbers, and if so what is it please?

[Ballot comment]
This was a discuss but is now a comment:

(1) "section 3.1: Is collision resistance needed for the case where the
Node-ID is a digest of the node's public key?  How is node key
rollover done?  Do I loose all stored data?  I think you need to
make all those clear.

This is now in 4.1, and the text is nearly ok. I'd suggest you
change the last para of 4.1 to say:

  In order to protect stored data from tampering, by other nodes, each
  stored value is individually digitally signed by the node which
  created it.  When a value is retrieved, the digital signature can be
  verified to detect tampering.  If the certificate used to verify the
  stored value signature expires, the value can no longer be retrieved (though may not
  be immediately garbage collected by the storing node) and the
  creating node will need to store the value again if it desires that stored
  value to continue to be available.


------------------------- OLD STUFF BELOW HERE --------------------

I've not gone thrrough to check any of these.

overall:

- I've got to say that this reads a lot like an experimental
specification. Its so complex and has so many moving parts and ways to
plug stuff in, I wonder if its really at the right stage for the
standards track. While I'm willing to believe the WG/AD that it is
(almost;-) ready, I'm still worried a bit that a whole bunch of things could
turn up when its deployed.

- The IPR declaration appears to be for something that has (as far as
I can see) nothing whatsoever to do with the protocol. Who knows, but
the filing seems to be about MIMO, which is a fairly low in the stack
thing to be related to an overlay on top of (D)TLS. Wouldn't it be
nice if that hadn't happened?

- This reminds me of DTNs [rfc4838,rfc5050] but witout the disruption
tolerance. Interestingly, if the timer defaults were made to be part
of the overlay then it could actually be used for a DTN.  I can also
imagine that other overlays might benefit from being able to modify
the timer defaults either up or down - so would it be worthwhile
allowing the overlay config to override or specify those default
values?

- There's a lot of lowercase occurrences of "must." It'd be great if
you could clean that up, e.g. saying if they're meant as RFC 2119
terms or not, e.g. 3.3's 1st few uses of "must" seem like they are
2119 terms, but not all others are, e.g. the last one in 3.2.

- A number of the detailed comments below were written as I was
reading the document, and relate to stuff that became clear as
I read further. If the comments says "but what about ?"
and  is explained later on, that means that I didn't get
on first reading to that point. You might want to consider
adding some text or a forward reference in some of those cases.
I've marked those with (*) in case you want to do that.

section 1:

- It'd be good to restate the peer/client distinction here (from e.g.
the charter) at the very top, e.g. moving the 2nd last para of 1.1
earlier

- Can "high performance" be quantified? If not, then is it really a
"feature"?

- Maybe add a reference to [Chord] in the intro?

section 1.1:

- "connected graph" assumes always-on? needs to be clear, maybe not a
great term

(*) I was wondering what the lifecycle of a Node-ID might be. It became
clear, but only *much* later.

- "also a storage network" - can I store my 24GB of photos using this?
if not (as I expect) then that'd be better stated here.

section 1.2.2:

- maybe clarify that you don't mean cryptographic keys

- add a reference for KBR

section 2:

(*) what's the lifecycle of a Kind-ID? are these also fixed length?

(*) what's the "fixed length" of a Node-ID?

(*) can a single peer/client instance be part of >1 overlay instance at
once? I guess that's just an implementation issue for the peer/client,
but wondered if there's anything that'd prevent that or make it hard.

- typo: "Nlocate" ?

- "Joining Peer" and "Admitting Peer" are those only for peers or
clients too? If the latter, then Node would be right I guess? Section
3 seems to imply that node would be more correct here.

- Connection Table definition refers to Attach handshakes and Updates
but those haven't been introduced yet. Might be better to use natural
language rather than those terms at this point if there's an easy way
to do that.

- Routing Table - the sentence "In general,..." is confusing. You also
use "Attached" but haven't yet said what that means. Maybe just say
that the routing table is a subset of the connection table if that's
the case.

(*) Destination List - isn't that a source route? If not, what's
different? If so, why not say so? Does it include the IDs through
which the message has already been routed or not? Later, (in 5.1.1) I
find out that the earlier IDs are dropped, saying that here would be
good. And also say that its not just Node-IDs, but also Resource-IDs,
that wasn't clear 1st time.

- The last paragraph here seems oddly detailed compared to the others
- would it be better elsewhere? As-is, there's not enough in this
paragraph for the reader to understand this having read to this point
so I think moving would be better. (Not sure where yet.)

section 3.1:

(*) how is the Node-ID included in the cert?

(*) what is "the user name found in the certificate"? that wasn't a
defined term - shouldn't it be? Where is it in the cert? is there just
one user name per cert/user/device?

- 3.1.1 is very short and needs references and maybe more.

section 3.2:

(*) this is the first time that the peer/client distinction and storage
have been mentioned together.  Are clients allowed to/required to be
able to store stuff?

- If peers "typically" have "storage responsibilities" does that mean
some peers may never store stuff?  How can the overlay tell if that's
the case and not try store stuff at that peer?

- 2nd para here is mostly a repeat. Better to not do that.

section 3.2.1:

- 2nd para/bullet needs some work. "The client can initiate..."
sentence has a few unclear instances of "it" and the following
sentence has one too ("to reach it").

- "learnable via other mechanisms" are those specifed?  if not, then
how will it work interoperably?

(*) the text about Node-IDs in certs and Attach/Ping can't be
understood at this stage in reading.

section 3.2.2:

- the list of things a client must (not MUST?) do could really do with
cross references to the relevant sections where a coder can find the
stuff they need.

(*) this says all client (and I guess peer) implementations are
overlay-specific, is that right?  if so, that seems to break the
architecture or does it?

section 3.3:

- what is "significant state"?

- Saying "In all cases, the response...needs to (be) delivered..."
seems to be a very hard requirement. Does this protocol really meet
that requirement?

- Saying "...and not to some other node." is odd. I'm not clear what
you really mean.

- I guess inverting the via list can fail if the topology has changed.
Is this handled? What happens?

- This is the 1st occurrence of the term "transaction id." That should
be in the terminolgy section really.  Who creates these and with what
scope (e.g.  do they need to be globally unique?)

- The figures in 3.3 could do with captions so they can be referenced.
(Same is true generally.)

- The text says that using a transaction id means not having to change
the message, but seems to involve changing the response message. If
so, that should be stated. If not, then briefly saying how that works
would be good.

section 3.4:

- This says that 3.2.1 describes a case of a direct connection to an
arbitrary IP address, but I didn't see mention of that there.

- "need to periodically verify" connections - I assume that's defined
later on in detailmentions

section 3.5:

- typo: using CHORD or Chord consistently would be better

section 3.5.2:

(*) I assume the cache TTL is specified later

- Does caching the set of nodes "it has connected to with public IP
addresses" mean a node has to know all the bogons and not cache those
or is the mention of "public" here just a reference to the bootstrap
phase?  (the grammar's not great there either, "nodes to which it has
connected" would be better:-)

- How is the first-ever-node case handled if the network is
temporarily entirely disconnected? Is there a need for a MUST NOT for
implementers that are developing "ordinary" nodes or something?
Without that, how can the node tell if its really the first one or
not?

section 3.6:

- the term "user" wasn't defined - I think it'd be worth doing that to
distinguish it from client/node.

section 3.6.1:

- What trust anchor is to be used for this HTTPS connection? (And add
a reference to 2818 I guess.)

- Does the HTTPS connection here need a reference to 6125? If not,
then is the overlay name supposed to be in the server cert? If not,
then how do I know I've been sent to the right place?

- section 3.6.2:

- If the config document says who's the trust anchor for the overlay
then it probably MUST be gotten securely. But that's not stated. If
this is done in the open, then being clear about the leap-of-faith
step would be good. I mean saying what's important there, exactly when
it happens, what might go wrong etc. That may be later but putting it
here (or a forward reference) seems like its needed.

section 4.1

(*) Signatures imply some c14n rule, esp if supporting
array/dictionary.  Is this covered?

section 4.2:

- the list could do with forward references to places where these
items are detailed.

- Didn't it say earlier that Resource-ID=hash(name) was just an
example?

- "...after a network partition." Do you mean "...after a network
partition is healed"? In any case that paragraph confuses me. This is
also the first mention of time sync, so a bit more introductory text
seems needed.

section 5.1:

- This is the 1st mention of the wildcard Node-ID, that should go in
section 2 as well and needs definition. I guess its like an anycast
and not a multicast, unless the overlay does some kind of message
replication.

section 5.1.1:

- This is the 1st time that I figured out that a Resource-ID could be
on a destination list. That should be stated in section 2 which
doesn't make that clear.

- The 2nd bullet says forward the thing but makes no mention of the
Via field. Isn't that needed? (5.1.2 does mention it.)

section 5.1.2:

- It seems odd to have the middle case in presentation order say "if
neither of the other ... apply" since I've not yet read 5.1.3. Maybe
re-order the sections?

- Should that say "neither of the other *two* cases"?  5.1 only has 3
bullets and "neither...three..." would be odd. Or am I missing even
more than usual;-)

- "likely to be responsible" is very wooly, as is "consults" the
routing table.

- Why is it a SHOULD for the case where the 1st entry is on the
connection table? Didn't you define the routing table just to make
this distinction?  If the SHOULD is right, then what's the exception?

- "This may be arranged in one of two ways..." and then you have two
MAY statements. There's a MUST missing here.

- The transaction ID example seems to have node C (or A or B) create
the transaction ID and not node D. That should be stated. (I assume
its really the initiator who creates it.)

- Saying "It MAY either be a compressed..." is a bit confusing. I
guess those aren't the only options? (I could encrypt the list to make
a private ID if I wanted, right?)

- What is "FORWARD_CRITICAL"? This seems like an odd place to
introduce the 3 second timer.

section 5.2:

- If alternative routing can be selected on a per-message basis and a
node doesn't support that routing scheme, then what does it do?  Drop
the message or use the MTI scheme? Or is this embedded in the overlay
name/ID?

section 5.3.2:

- Is the overlay name that is hashed into the overlay 32 bit value
case (in)sensitive or just treated as octets? If SRV records are used
bootstrapping for this I guess something may need to be said about
this.

- "MUST be randomly generated" - it'd be good to give guidance here
about PRNGs, e.g. maybe cite 4086?

- You don't say where to put a new entry in the via_list.  I assume
its at the end furthest from the start of the message.

section 5.3.2.2

- compressed_id was earlier called private ID - why change?

section 5.3.2.3

- the struct has flags before length but the descriptions are length
and then flags. But the length desription says "...rest of the
structure" which could be interpreted to include the flags field. I
guess it oughtn't and just moving the length description should fix
this. Also saying the option value is "length" bytes would be good and
giving an exanple of how to handle length==0 would help too.

section 5.3.3:

- The criticial field in extensions has proved to be slightly
problematic in X.509 over the years. The debate arises now and then as
to what "understand the message" means, with some saying just knowing
the type means you understand it, others saying you need to be able to
do all processing defined for the extension type and some in between.
It would be good to be more specific here about what "understand the
message" means, for example saying that any relevant MUSTs and SHOULDs
are supported or something like that. I'm happy to remove this discuss
point as soon as I'm told the WG thought about this and its ok as-is,
but wanted to check.

section 5.3.3.1

- error_info is a UTF-8 string unless otherwise stated. Is this
intended for human consumption or not? If so, then how are language
issues to be handled?

- I'm not clear as to whether the error_info for the various
error_code values is expected to be as described here. For example, if
the error is Error_Forbidden, does the description of that imply
something about what goes into error_info or not?

- typo: Error_Data_Too_old is repeated.

section 5.3.4:

- might be no harm to also say that the NodeID in H(NodeID ||
certificate) MUST be in network byte order? Saying "simple raw bytes"
could cause endian-issues there.

- This says that "receiving nodes" MUST verify the signature. Earlier
it said that nodes just need to check formatting (in 5.1). That seems
to be a conflict.  See also discuss point (2).

- I don't get how the first additional check works if the response has
a via - I thought that that meant that the nodes on the path for the
response didn't need state? If so, then how does the verifier here
know who originated the request to which this is a response?

- The 2nd additional check is a bit unclear for me. It says that
response-sender-node-ID MUST be as close or closer to the resource-id
in the *requesting node's* neighbour table. How does a verifier in the
middle of the path get to see the requesting node's neighbour table?

section 5.4.1:

- Has anyone specified a topology plugin other than the MTI one from
here? I'm wondering if the list here is really complete and doable.
(It'd be easy to get this wrong.)

section 5.4.2.1:

- Which error SHOULD nodes sent if they cannot form connections?

section 5.6.3.1:

- Is the "no more aggressive than TFRC" sentence here clear?

section 6.1:

- given that the StoredDataValue can be up to 4GB would it be better
to put the SignerIdentity before that in the signature input? That
might help the verifier go quicker in the case of LARGE data values I
guess.

section 6.2:

- Is 2^32-1 octets really expected to be supported here? Might there
be a case for distinguishing small (say up to N KB) from larger data
values?  (Just checking)

section 6.2.3:

- it'd be no harm to say what you get when a non-existent dictionary
key is used in a query, as you did in 6.2.2 for arrays.

section 6.4.1.1:

- this introduces the "anonymous" and "none" values for
SignatureAndHashAlgorithm on page 88.  That really needs to be
introduced where signing is first discussed and you need to say when
its allowed to be used and for what. (In this part you just say it
cannot be used.)

section 6.4.1.3:

- "(unlike previous versions)" - if there's nothing you can reference
then I'd suggest taking this out - it might have been useful for the
WG but might just confuse the RFC reader.

section 6.4.2.1:

- I don't get the last sentence - how does the requester ask for the
user's cert? And should that say owner's cert? (That may be just due
to how long it's taken me to read this, at multiple sittings;-)

section 8:

- You should probably add a reference for the "private address range"
and think about whether or not the putative new private allocation
counts there too. (It may be that getting this document finished takes
long enough that that process is done.)

section 9.7:

- You RECOMMEND that a peer maintain O(log(N)) things in the neighbour
set. I'm not clear how the peer knows the value of N there?

section 10.1

- This is not right! Why not use a real  in the example?
If the example could be verified that'd help coders.

- You might say is ascii-hex values can be mixed case or not. Be a
shame to fall over because of that and coders might make different
assumptions.

- Why are we not using XMLDSIG for the signatures here?  (Only
kidding:-)

section 10.2

- s/by determines/by determining/

- Isn't RFC6125 a better reference here than 2818?

- Does this practically mean that overlays should be named using DNS
names? If so, saying that early would be good rather than on p124.

- s/such an/such as an/

section 10.3:

- Does the enrollment server web server cert have to have any
relationship with the configuration?  I don't think that's needed, but
am not sure. It'd be good to say either way though.

- Using HTTP errors is fairly coarse grained. In particular don't you
want to have a way to say "everything's fine but you asked for too
many nodeids"? If there's a good HTTP error for that then calling it
out would be good. Just a bare 4xx for username/password errors is
fine though.

section 12:

- Do you need to reference the TLS re-negotiation bug RFC?  Would it
have a bad impact here? (Not sure.)

section 13.5

- I don't get why you have two SIP entries there. It'd be nice to
know.

[Ballot comment]
Thanks for addressing my Discuss and nearly all my Comments by the -24 revision.
I'm impressed by the work.

Sorry if we already discussed the remaining Comments in an email thread. I record them here in case they were accidentally missed.

---

3.2.2

  calculating the Resource-ID
  requires an implementation of the appropriate algorithm for the
  overlay.

This discussion of an algorithm (and, indeed, calculating a Resource-ID)
is novel. Isn't it enough to say that a client must sufficiently
understand the nature of the overlay network to be able to determine the
correct Resource-IDs to use?

---

Section 3.3

  Low state:    RELOAD's routing algorithms must not require
      significant state to be stored on intermediate peers.

"Significant" is subjective. What does this requirement mean?

[Ballot discuss]
Many thanks again for all the work that's gone into -24!

(1) cleared

(2) cleared

(3) cleared

(4) cleared

(5) cleared

(6) cleared

(7) cleared

(8) cleared

(9) cleared

(10) cleared

(11) cleared

(12) section 7: I don't see how to send a reference to a certificate -
5.3.4 doesn't seem to allow for that now - wouldn't you need a new
CertificateType for that?

(13) section 10.1: I don't get  - is that mode really
well-specified? Seems like you're publishing a shared-secret which
isn't really secret then is it? Or did I miss something? Maybe you
want to say that configurations that use this MUST NOT be publically
available and MUST be locally installed in a trusted way or something
like that?

(14) section 10.1: You don't say here that the signature(s) MUST
verify for the configuration to be used. Neither do you say that the
signers MUST chain up to the one of the root-cert values included in
the configuration.  I think you could justify not requiring that, but
then you should say so, so that coder's don't do the wrong thing.

(15) section 10.3: Putting the password (or even username) in the
query string is not good practice - those can get logged by servers
accidentally far too easily. Why don't you define a HTML form that you
then POST?

(16) section 10.3: might need to warn against dodgy username values,
e.g.  containing a null character or whatever. I think you need some
more rules there to end up with a safe rfc822name in the cert. (Or
else have an argument that that's not a problem for RELOAD - it has
been a problem elsewhere.) Also, does the enrollment server choose the
domain component of the rfc822 name or may that be supplied by the
client?

(17) section 10.3: What character set is allowed for passwords? What
if something is URL escaped - what's going to match?  I'm sure you can
copy from somewhere else, not quite sure what's best though. 

(18) section 10.3: You say the signer for this exchange MUST be one of
the root-certs from the configuration. I think that that ought say
that it MUST be a CA and it MUST chain up to one of the root-certs.
Why force the root to be online like that?  Or, you could add a new
configuration setting for a user-signing-ca-cert and then it'd be ok
to say that one of those MUST be used for enrollment.

= You could probably say that if this is not a new configuration and
has a root-cert that is common with a previous configuration then the
outet signature MUST verify and MUST chain up to the previous
root-cert.

= I think you can say that the kind-signatures MUST verify and MUST
chain up to a root-cert from the current configuration.

= I think you can say that implementations SHOULD provide a way to
allow completely new configurations, or configuration updates with
only-new root-certs to be accepted but that that's out of scope.

(19) section 13.15: is reg-name sufficiently clear for the overlay
name?  For example, that allows percent encoding - are those variant
names all the same overlay? I guess so, but it'd be good to confirm
and maybe say that in the document.

[Ballot comment]
These were discusses and are now comments. The number was
the discuss point.

(1) "section 3.1: Is collision resistance needed for the case where the
Node-ID is a digest of the node's public key?  How is node key
rollover done?  Do I loose all stored data?  I think you need to
make all those clear.

This is now in 4.1, and the text is nearly ok. I'd suggest you
change the last para of 4.1 to say:

  In order to protect stored data from tampering, by other nodes, each
  stored value is individually digitally signed by the node which
  created it.  When a value is retrieved, the digital signature can be
  verified to detect tampering.  If the certificate used to verify the
  stored value signature expires, the value can no longer be retrieved (though may not
  be immediately garbage collected by the storing node) and the
  creating node will need to store the value again if it desires that stored
  value to continue to be available.




------------------------- OLD STUFF BELOW HERE --------------------

overall:

- I've got to say that this reads a lot like an experimental
specification. Its so complex and has so many moving parts and ways to
plug stuff in, I wonder if its really at the right stage for the
standards track. While I'm willing to believe the WG/AD that it is
(almost;-) ready, I'm still worried a bit that a whole bunch of things could
turn up when its deployed.

- The IPR declaration appears to be for something that has (as far as
I can see) nothing whatsoever to do with the protocol. Who knows, but
the filing seems to be about MIMO, which is a fairly low in the stack
thing to be related to an overlay on top of (D)TLS. Wouldn't it be
nice if that hadn't happened?

- This reminds me of DTNs [rfc4838,rfc5050] but witout the disruption
tolerance. Interestingly, if the timer defaults were made to be part
of the overlay then it could actually be used for a DTN.  I can also
imagine that other overlays might benefit from being able to modify
the timer defaults either up or down - so would it be worthwhile
allowing the overlay config to override or specify those default
values?

- There's a lot of lowercase occurrences of "must." It'd be great if
you could clean that up, e.g. saying if they're meant as RFC 2119
terms or not, e.g. 3.3's 1st few uses of "must" seem like they are
2119 terms, but not all others are, e.g. the last one in 3.2.

- A number of the detailed comments below were written as I was
reading the document, and relate to stuff that became clear as
I read further. If the comments says "but what about ?"
and  is explained later on, that means that I didn't get
on first reading to that point. You might want to consider
adding some text or a forward reference in some of those cases.
I've marked those with (*) in case you want to do that.

section 1:

- It'd be good to restate the peer/client distinction here (from e.g.
the charter) at the very top, e.g. moving the 2nd last para of 1.1
earlier

- Can "high performance" be quantified? If not, then is it really a
"feature"?

- Maybe add a reference to [Chord] in the intro?

section 1.1:

- "connected graph" assumes always-on? needs to be clear, maybe not a
great term

(*) I was wondering what the lifecycle of a Node-ID might be. It became
clear, but only *much* later.

- "also a storage network" - can I store my 24GB of photos using this?
if not (as I expect) then that'd be better stated here.

section 1.2.2:

- maybe clarify that you don't mean cryptographic keys

- add a reference for KBR

section 2:

(*) what's the lifecycle of a Kind-ID? are these also fixed length?

(*) what's the "fixed length" of a Node-ID?

(*) can a single peer/client instance be part of >1 overlay instance at
once? I guess that's just an implementation issue for the peer/client,
but wondered if there's anything that'd prevent that or make it hard.

- typo: "Nlocate" ?

- "Joining Peer" and "Admitting Peer" are those only for peers or
clients too? If the latter, then Node would be right I guess? Section
3 seems to imply that node would be more correct here.

- Connection Table definition refers to Attach handshakes and Updates
but those haven't been introduced yet. Might be better to use natural
language rather than those terms at this point if there's an easy way
to do that.

- Routing Table - the sentence "In general,..." is confusing. You also
use "Attached" but haven't yet said what that means. Maybe just say
that the routing table is a subset of the connection table if that's
the case.

(*) Destination List - isn't that a source route? If not, what's
different? If so, why not say so? Does it include the IDs through
which the message has already been routed or not? Later, (in 5.1.1) I
find out that the earlier IDs are dropped, saying that here would be
good. And also say that its not just Node-IDs, but also Resource-IDs,
that wasn't clear 1st time.

- The last paragraph here seems oddly detailed compared to the others
- would it be better elsewhere? As-is, there's not enough in this
paragraph for the reader to understand this having read to this point
so I think moving would be better. (Not sure where yet.)

section 3.1:

(*) how is the Node-ID included in the cert?

(*) what is "the user name found in the certificate"? that wasn't a
defined term - shouldn't it be? Where is it in the cert? is there just
one user name per cert/user/device?

- 3.1.1 is very short and needs references and maybe more.

section 3.2:

(*) this is the first time that the peer/client distinction and storage
have been mentioned together.  Are clients allowed to/required to be
able to store stuff?

- If peers "typically" have "storage responsibilities" does that mean
some peers may never store stuff?  How can the overlay tell if that's
the case and not try store stuff at that peer?

- 2nd para here is mostly a repeat. Better to not do that.

section 3.2.1:

- 2nd para/bullet needs some work. "The client can initiate..."
sentence has a few unclear instances of "it" and the following
sentence has one too ("to reach it").

- "learnable via other mechanisms" are those specifed?  if not, then
how will it work interoperably?

(*) the text about Node-IDs in certs and Attach/Ping can't be
understood at this stage in reading.

section 3.2.2:

- the list of things a client must (not MUST?) do could really do with
cross references to the relevant sections where a coder can find the
stuff they need.

(*) this says all client (and I guess peer) implementations are
overlay-specific, is that right?  if so, that seems to break the
architecture or does it?

section 3.3:

- what is "significant state"?

- Saying "In all cases, the response...needs to (be) delivered..."
seems to be a very hard requirement. Does this protocol really meet
that requirement?

- Saying "...and not to some other node." is odd. I'm not clear what
you really mean.

- I guess inverting the via list can fail if the topology has changed.
Is this handled? What happens?

- This is the 1st occurrence of the term "transaction id." That should
be in the terminolgy section really.  Who creates these and with what
scope (e.g.  do they need to be globally unique?)

- The figures in 3.3 could do with captions so they can be referenced.
(Same is true generally.)

- The text says that using a transaction id means not having to change
the message, but seems to involve changing the response message. If
so, that should be stated. If not, then briefly saying how that works
would be good.

section 3.4:

- This says that 3.2.1 describes a case of a direct connection to an
arbitrary IP address, but I didn't see mention of that there.

- "need to periodically verify" connections - I assume that's defined
later on in detailmentions

section 3.5:

- typo: using CHORD or Chord consistently would be better

section 3.5.2:

(*) I assume the cache TTL is specified later

- Does caching the set of nodes "it has connected to with public IP
addresses" mean a node has to know all the bogons and not cache those
or is the mention of "public" here just a reference to the bootstrap
phase?  (the grammar's not great there either, "nodes to which it has
connected" would be better:-)

- How is the first-ever-node case handled if the network is
temporarily entirely disconnected? Is there a need for a MUST NOT for
implementers that are developing "ordinary" nodes or something?
Without that, how can the node tell if its really the first one or
not?

section 3.6:

- the term "user" wasn't defined - I think it'd be worth doing that to
distinguish it from client/node.

section 3.6.1:

- What trust anchor is to be used for this HTTPS connection? (And add
a reference to 2818 I guess.)

- Does the HTTPS connection here need a reference to 6125? If not,
then is the overlay name supposed to be in the server cert? If not,
then how do I know I've been sent to the right place?

- section 3.6.2:

- If the config document says who's the trust anchor for the overlay
then it probably MUST be gotten securely. But that's not stated. If
this is done in the open, then being clear about the leap-of-faith
step would be good. I mean saying what's important there, exactly when
it happens, what might go wrong etc. That may be later but putting it
here (or a forward reference) seems like its needed.

section 4.1

(*) Signatures imply some c14n rule, esp if supporting
array/dictionary.  Is this covered?

section 4.2:

- the list could do with forward references to places where these
items are detailed.

- Didn't it say earlier that Resource-ID=hash(name) was just an
example?

- "...after a network partition." Do you mean "...after a network
partition is healed"? In any case that paragraph confuses me. This is
also the first mention of time sync, so a bit more introductory text
seems needed.

section 5.1:

- This is the 1st mention of the wildcard Node-ID, that should go in
section 2 as well and needs definition. I guess its like an anycast
and not a multicast, unless the overlay does some kind of message
replication.

section 5.1.1:

- This is the 1st time that I figured out that a Resource-ID could be
on a destination list. That should be stated in section 2 which
doesn't make that clear.

- The 2nd bullet says forward the thing but makes no mention of the
Via field. Isn't that needed? (5.1.2 does mention it.)

section 5.1.2:

- It seems odd to have the middle case in presentation order say "if
neither of the other ... apply" since I've not yet read 5.1.3. Maybe
re-order the sections?

- Should that say "neither of the other *two* cases"?  5.1 only has 3
bullets and "neither...three..." would be odd. Or am I missing even
more than usual;-)

- "likely to be responsible" is very wooly, as is "consults" the
routing table.

- Why is it a SHOULD for the case where the 1st entry is on the
connection table? Didn't you define the routing table just to make
this distinction?  If the SHOULD is right, then what's the exception?

- "This may be arranged in one of two ways..." and then you have two
MAY statements. There's a MUST missing here.

- The transaction ID example seems to have node C (or A or B) create
the transaction ID and not node D. That should be stated. (I assume
its really the initiator who creates it.)

- Saying "It MAY either be a compressed..." is a bit confusing. I
guess those aren't the only options? (I could encrypt the list to make
a private ID if I wanted, right?)

- What is "FORWARD_CRITICAL"? This seems like an odd place to
introduce the 3 second timer.

section 5.2:

- If alternative routing can be selected on a per-message basis and a
node doesn't support that routing scheme, then what does it do?  Drop
the message or use the MTI scheme? Or is this embedded in the overlay
name/ID?

section 5.3.2:

- Is the overlay name that is hashed into the overlay 32 bit value
case (in)sensitive or just treated as octets? If SRV records are used
bootstrapping for this I guess something may need to be said about
this.

- "MUST be randomly generated" - it'd be good to give guidance here
about PRNGs, e.g. maybe cite 4086?

- You don't say where to put a new entry in the via_list.  I assume
its at the end furthest from the start of the message.

section 5.3.2.2

- compressed_id was earlier called private ID - why change?

section 5.3.2.3

- the struct has flags before length but the descriptions are length
and then flags. But the length desription says "...rest of the
structure" which could be interpreted to include the flags field. I
guess it oughtn't and just moving the length description should fix
this. Also saying the option value is "length" bytes would be good and
giving an exanple of how to handle length==0 would help too.

section 5.3.3:

- The criticial field in extensions has proved to be slightly
problematic in X.509 over the years. The debate arises now and then as
to what "understand the message" means, with some saying just knowing
the type means you understand it, others saying you need to be able to
do all processing defined for the extension type and some in between.
It would be good to be more specific here about what "understand the
message" means, for example saying that any relevant MUSTs and SHOULDs
are supported or something like that. I'm happy to remove this discuss
point as soon as I'm told the WG thought about this and its ok as-is,
but wanted to check.

section 5.3.3.1

- error_info is a UTF-8 string unless otherwise stated. Is this
intended for human consumption or not? If so, then how are language
issues to be handled?

- I'm not clear as to whether the error_info for the various
error_code values is expected to be as described here. For example, if
the error is Error_Forbidden, does the description of that imply
something about what goes into error_info or not?

- typo: Error_Data_Too_old is repeated.

section 5.3.4:

- might be no harm to also say that the NodeID in H(NodeID ||
certificate) MUST be in network byte order? Saying "simple raw bytes"
could cause endian-issues there.

- This says that "receiving nodes" MUST verify the signature. Earlier
it said that nodes just need to check formatting (in 5.1). That seems
to be a conflict.  See also discuss point (2).

- I don't get how the first additional check works if the response has
a via - I thought that that meant that the nodes on the path for the
response didn't need state? If so, then how does the verifier here
know who originated the request to which this is a response?

- The 2nd additional check is a bit unclear for me. It says that
response-sender-node-ID MUST be as close or closer to the resource-id
in the *requesting node's* neighbour table. How does a verifier in the
middle of the path get to see the requesting node's neighbour table?

section 5.4.1:

- Has anyone specified a topology plugin other than the MTI one from
here? I'm wondering if the list here is really complete and doable.
(It'd be easy to get this wrong.)

section 5.4.2.1:

- Which error SHOULD nodes sent if they cannot form connections?

section 5.6.3.1:

- Is the "no more aggressive than TFRC" sentence here clear?

section 6.1:

- given that the StoredDataValue can be up to 4GB would it be better
to put the SignerIdentity before that in the signature input? That
might help the verifier go quicker in the case of LARGE data values I
guess.

section 6.2:

- Is 2^32-1 octets really expected to be supported here? Might there
be a case for distinguishing small (say up to N KB) from larger data
values?  (Just checking)

section 6.2.3:

- it'd be no harm to say what you get when a non-existent dictionary
key is used in a query, as you did in 6.2.2 for arrays.

section 6.4.1.1:

- this introduces the "anonymous" and "none" values for
SignatureAndHashAlgorithm on page 88.  That really needs to be
introduced where signing is first discussed and you need to say when
its allowed to be used and for what. (In this part you just say it
cannot be used.)

section 6.4.1.3:

- "(unlike previous versions)" - if there's nothing you can reference
then I'd suggest taking this out - it might have been useful for the
WG but might just confuse the RFC reader.

section 6.4.2.1:

- I don't get the last sentence - how does the requester ask for the
user's cert? And should that say owner's cert? (That may be just due
to how long it's taken me to read this, at multiple sittings;-)

section 8:

- You should probably add a reference for the "private address range"
and think about whether or not the putative new private allocation
counts there too. (It may be that getting this document finished takes
long enough that that process is done.)

section 9.7:

- You RECOMMEND that a peer maintain O(log(N)) things in the neighbour
set. I'm not clear how the peer knows the value of N there?

section 10.1

- This is not right! Why not use a real  in the example?
If the example could be verified that'd help coders.

- You might say is ascii-hex values can be mixed case or not. Be a
shame to fall over because of that and coders might make different
assumptions.

- Why are we not using XMLDSIG for the signatures here?  (Only
kidding:-)

section 10.2

- s/by determines/by determining/

- Isn't RFC6125 a better reference here than 2818?

- Does this practically mean that overlays should be named using DNS
names? If so, saying that early would be good rather than on p124.

- s/such an/such as an/

section 10.3:

- Does the enrollment server web server cert have to have any
relationship with the configuration?  I don't think that's needed, but
am not sure. It'd be good to say either way though.

- Using HTTP errors is fairly coarse grained. In particular don't you
want to have a way to say "everything's fine but you asked for too
many nodeids"? If there's a good HTTP error for that then calling it
out would be good. Just a bare 4xx for username/password errors is
fine though.

section 12:

- Do you need to reference the TLS re-negotiation bug RFC?  Would it
have a bad impact here? (Not sure.)

section 13.5

- I don't get why you have two SIP entries there. It'd be nice to
know.

[Ballot discuss]

Many thanks again for all the work that's gone into -24!

(1) cleared

(2) cleared

(3) cleared

(4) cleared

(5) cleared

(6) cleared

(7) cleared

(8) cleared

(9) cleared

(10) cleared

(11) section 6.4.2.2:  If the signer's cert has expired, is a
signature on a stored value still considered valid or not?  One issue
is that if any revocation/status checking is supported then there may
not be any such information available for expired certs. Another issue
is that if you do consider signatures only verifiable with non-expired
certs, then a lot can go wrong when a cert expires and its hard to fix
that up. I don't have a good solution to offer, but maybe you have an
answer?

(12) section 7: I don't see how to send a reference to a certificate -
5.3.4 doesn't seem to allow for that now - wouldn't you need a new
CertificateType for that?

(13) section 10.1: I don't get  - is that mode really
well-specified? Seems like you're publishing a shared-secret which
isn't really secret then is it? Or did I miss something? Maybe you
want to say that configurations that use this MUST NOT be publically
available and MUST be locally installed in a trusted way or something
like that?

(14) section 10.1: You don't say here that the signature(s) MUST
verify for the configuration to be used. Neither do you say that the
signers MUST chain up to the one of the root-cert values included in
the configuration.  I think you could justify not requiring that, but
then you should say so, so that coder's don't do the wrong thing.

(15) section 10.3: Putting the password (or even username) in the
query string is not good practice - those can get logged by servers
accidentally far too easily. Why don't you define a HTML form that you
then POST?

(16) section 10.3: might need to warn against dodgy username values,
e.g.  containing a null character or whatever. I think you need some
more rules there to end up with a safe rfc822name in the cert. (Or
else have an argument that that's not a problem for RELOAD - it has
been a problem elsewhere.) Also, does the enrollment server choose the
domain component of the rfc822 name or may that be supplied by the
client?

(17) section 10.3: What character set is allowed for passwords? What
if something is URL escaped - what's going to match?  I'm sure you can
copy from somewhere else, not quite sure what's best though. 

(18) section 10.3: You say the signer for this exchange MUST be one of
the root-certs from the configuration. I think that that ought say
that it MUST be a CA and it MUST chain up to one of the root-certs.
Why force the root to be online like that?  Or, you could add a new
configuration setting for a user-signing-ca-cert and then it'd be ok
to say that one of those MUST be used for enrollment.

= You could probably say that if this is not a new configuration and
has a root-cert that is common with a previous configuration then the
outet signature MUST verify and MUST chain up to the previous
root-cert.

= I think you can say that the kind-signatures MUST verify and MUST
chain up to a root-cert from the current configuration.

= I think you can say that implementations SHOULD provide a way to
allow completely new configurations, or configuration updates with
only-new root-certs to be accepted but that that's out of scope.

(19) section 13.15: is reg-name sufficiently clear for the overlay
name?  For example, that allows percent encoding - are those variant
names all the same overlay? I guess so, but it'd be good to confirm
and maybe say that in the document.

[Ballot comment]

These were discusses and are now comments. The number was
the discuss point.

(1) "section 3.1: Is collision resistance needed for the case where the
Node-ID is a digest of the node's public key?  How is node key
rollover done?  Do I loose all stored data?  I think you need to
make all those clear.

This is now in 4.1, and the text is nearly ok. I'd suggest you
change the last para of 4.1 to say:

  In order to protect stored data from tampering, by other nodes, each
  stored value is individually digitally signed by the node which
  created it.  When a value is retrieved, the digital signature can be
  verified to detect tampering.  If the certificate used to verify the
  stored value signature expires, the value can no longer be retrieved (though may not
  be immediately garbage collected by the storing node) and the
  creating node will need to store the value again if it desires that stored
  value to continue to be available.




------------------------- OLD STUFF BELOW HERE --------------------

overall:

- I've got to say that this reads a lot like an experimental
specification. Its so complex and has so many moving parts and ways to
plug stuff in, I wonder if its really at the right stage for the
standards track. While I'm willing to believe the WG/AD that it is
(almost;-) ready, I'm still worried a bit that a whole bunch of things could
turn up when its deployed.

- The IPR declaration appears to be for something that has (as far as
I can see) nothing whatsoever to do with the protocol. Who knows, but
the filing seems to be about MIMO, which is a fairly low in the stack
thing to be related to an overlay on top of (D)TLS. Wouldn't it be
nice if that hadn't happened?

- This reminds me of DTNs [rfc4838,rfc5050] but witout the disruption
tolerance. Interestingly, if the timer defaults were made to be part
of the overlay then it could actually be used for a DTN.  I can also
imagine that other overlays might benefit from being able to modify
the timer defaults either up or down - so would it be worthwhile
allowing the overlay config to override or specify those default
values?

- There's a lot of lowercase occurrences of "must." It'd be great if
you could clean that up, e.g. saying if they're meant as RFC 2119
terms or not, e.g. 3.3's 1st few uses of "must" seem like they are
2119 terms, but not all others are, e.g. the last one in 3.2.

- A number of the detailed comments below were written as I was
reading the document, and relate to stuff that became clear as
I read further. If the comments says "but what about ?"
and  is explained later on, that means that I didn't get
on first reading to that point. You might want to consider
adding some text or a forward reference in some of those cases.
I've marked those with (*) in case you want to do that.

section 1:

- It'd be good to restate the peer/client distinction here (from e.g.
the charter) at the very top, e.g. moving the 2nd last para of 1.1
earlier

- Can "high performance" be quantified? If not, then is it really a
"feature"?

- Maybe add a reference to [Chord] in the intro?

section 1.1:

- "connected graph" assumes always-on? needs to be clear, maybe not a
great term

(*) I was wondering what the lifecycle of a Node-ID might be. It became
clear, but only *much* later.

- "also a storage network" - can I store my 24GB of photos using this?
if not (as I expect) then that'd be better stated here.

section 1.2.2:

- maybe clarify that you don't mean cryptographic keys

- add a reference for KBR

section 2:

(*) what's the lifecycle of a Kind-ID? are these also fixed length?

(*) what's the "fixed length" of a Node-ID?

(*) can a single peer/client instance be part of >1 overlay instance at
once? I guess that's just an implementation issue for the peer/client,
but wondered if there's anything that'd prevent that or make it hard.

- typo: "Nlocate" ?

- "Joining Peer" and "Admitting Peer" are those only for peers or
clients too? If the latter, then Node would be right I guess? Section
3 seems to imply that node would be more correct here.

- Connection Table definition refers to Attach handshakes and Updates
but those haven't been introduced yet. Might be better to use natural
language rather than those terms at this point if there's an easy way
to do that.

- Routing Table - the sentence "In general,..." is confusing. You also
use "Attached" but haven't yet said what that means. Maybe just say
that the routing table is a subset of the connection table if that's
the case.

(*) Destination List - isn't that a source route? If not, what's
different? If so, why not say so? Does it include the IDs through
which the message has already been routed or not? Later, (in 5.1.1) I
find out that the earlier IDs are dropped, saying that here would be
good. And also say that its not just Node-IDs, but also Resource-IDs,
that wasn't clear 1st time.

- The last paragraph here seems oddly detailed compared to the others
- would it be better elsewhere? As-is, there's not enough in this
paragraph for the reader to understand this having read to this point
so I think moving would be better. (Not sure where yet.)

section 3.1:

(*) how is the Node-ID included in the cert?

(*) what is "the user name found in the certificate"? that wasn't a
defined term - shouldn't it be? Where is it in the cert? is there just
one user name per cert/user/device?

- 3.1.1 is very short and needs references and maybe more.

section 3.2:

(*) this is the first time that the peer/client distinction and storage
have been mentioned together.  Are clients allowed to/required to be
able to store stuff?

- If peers "typically" have "storage responsibilities" does that mean
some peers may never store stuff?  How can the overlay tell if that's
the case and not try store stuff at that peer?

- 2nd para here is mostly a repeat. Better to not do that.

section 3.2.1:

- 2nd para/bullet needs some work. "The client can initiate..."
sentence has a few unclear instances of "it" and the following
sentence has one too ("to reach it").

- "learnable via other mechanisms" are those specifed?  if not, then
how will it work interoperably?

(*) the text about Node-IDs in certs and Attach/Ping can't be
understood at this stage in reading.

section 3.2.2:

- the list of things a client must (not MUST?) do could really do with
cross references to the relevant sections where a coder can find the
stuff they need.

(*) this says all client (and I guess peer) implementations are
overlay-specific, is that right?  if so, that seems to break the
architecture or does it?

section 3.3:

- what is "significant state"?

- Saying "In all cases, the response...needs to (be) delivered..."
seems to be a very hard requirement. Does this protocol really meet
that requirement?

- Saying "...and not to some other node." is odd. I'm not clear what
you really mean.

- I guess inverting the via list can fail if the topology has changed.
Is this handled? What happens?

- This is the 1st occurrence of the term "transaction id." That should
be in the terminolgy section really.  Who creates these and with what
scope (e.g.  do they need to be globally unique?)

- The figures in 3.3 could do with captions so they can be referenced.
(Same is true generally.)

- The text says that using a transaction id means not having to change
the message, but seems to involve changing the response message. If
so, that should be stated. If not, then briefly saying how that works
would be good.

section 3.4:

- This says that 3.2.1 describes a case of a direct connection to an
arbitrary IP address, but I didn't see mention of that there.

- "need to periodically verify" connections - I assume that's defined
later on in detailmentions

section 3.5:

- typo: using CHORD or Chord consistently would be better

section 3.5.2:

(*) I assume the cache TTL is specified later

- Does caching the set of nodes "it has connected to with public IP
addresses" mean a node has to know all the bogons and not cache those
or is the mention of "public" here just a reference to the bootstrap
phase?  (the grammar's not great there either, "nodes to which it has
connected" would be better:-)

- How is the first-ever-node case handled if the network is
temporarily entirely disconnected? Is there a need for a MUST NOT for
implementers that are developing "ordinary" nodes or something?
Without that, how can the node tell if its really the first one or
not?

section 3.6:

- the term "user" wasn't defined - I think it'd be worth doing that to
distinguish it from client/node.

section 3.6.1:

- What trust anchor is to be used for this HTTPS connection? (And add
a reference to 2818 I guess.)

- Does the HTTPS connection here need a reference to 6125? If not,
then is the overlay name supposed to be in the server cert? If not,
then how do I know I've been sent to the right place?

- section 3.6.2:

- If the config document says who's the trust anchor for the overlay
then it probably MUST be gotten securely. But that's not stated. If
this is done in the open, then being clear about the leap-of-faith
step would be good. I mean saying what's important there, exactly when
it happens, what might go wrong etc. That may be later but putting it
here (or a forward reference) seems like its needed.

section 4.1

(*) Signatures imply some c14n rule, esp if supporting
array/dictionary.  Is this covered?

section 4.2:

- the list could do with forward references to places where these
items are detailed.

- Didn't it say earlier that Resource-ID=hash(name) was just an
example?

- "...after a network partition." Do you mean "...after a network
partition is healed"? In any case that paragraph confuses me. This is
also the first mention of time sync, so a bit more introductory text
seems needed.

section 5.1:

- This is the 1st mention of the wildcard Node-ID, that should go in
section 2 as well and needs definition. I guess its like an anycast
and not a multicast, unless the overlay does some kind of message
replication.

section 5.1.1:

- This is the 1st time that I figured out that a Resource-ID could be
on a destination list. That should be stated in section 2 which
doesn't make that clear.

- The 2nd bullet says forward the thing but makes no mention of the
Via field. Isn't that needed? (5.1.2 does mention it.)

section 5.1.2:

- It seems odd to have the middle case in presentation order say "if
neither of the other ... apply" since I've not yet read 5.1.3. Maybe
re-order the sections?

- Should that say "neither of the other *two* cases"?  5.1 only has 3
bullets and "neither...three..." would be odd. Or am I missing even
more than usual;-)

- "likely to be responsible" is very wooly, as is "consults" the
routing table.

- Why is it a SHOULD for the case where the 1st entry is on the
connection table? Didn't you define the routing table just to make
this distinction?  If the SHOULD is right, then what's the exception?

- "This may be arranged in one of two ways..." and then you have two
MAY statements. There's a MUST missing here.

- The transaction ID example seems to have node C (or A or B) create
the transaction ID and not node D. That should be stated. (I assume
its really the initiator who creates it.)

- Saying "It MAY either be a compressed..." is a bit confusing. I
guess those aren't the only options? (I could encrypt the list to make
a private ID if I wanted, right?)

- What is "FORWARD_CRITICAL"? This seems like an odd place to
introduce the 3 second timer.

section 5.2:

- If alternative routing can be selected on a per-message basis and a
node doesn't support that routing scheme, then what does it do?  Drop
the message or use the MTI scheme? Or is this embedded in the overlay
name/ID?

section 5.3.2:

- Is the overlay name that is hashed into the overlay 32 bit value
case (in)sensitive or just treated as octets? If SRV records are used
bootstrapping for this I guess something may need to be said about
this.

- "MUST be randomly generated" - it'd be good to give guidance here
about PRNGs, e.g. maybe cite 4086?

- You don't say where to put a new entry in the via_list.  I assume
its at the end furthest from the start of the message.

section 5.3.2.2

- compressed_id was earlier called private ID - why change?

section 5.3.2.3

- the struct has flags before length but the descriptions are length
and then flags. But the length desription says "...rest of the
structure" which could be interpreted to include the flags field. I
guess it oughtn't and just moving the length description should fix
this. Also saying the option value is "length" bytes would be good and
giving an exanple of how to handle length==0 would help too.

section 5.3.3:

- The criticial field in extensions has proved to be slightly
problematic in X.509 over the years. The debate arises now and then as
to what "understand the message" means, with some saying just knowing
the type means you understand it, others saying you need to be able to
do all processing defined for the extension type and some in between.
It would be good to be more specific here about what "understand the
message" means, for example saying that any relevant MUSTs and SHOULDs
are supported or something like that. I'm happy to remove this discuss
point as soon as I'm told the WG thought about this and its ok as-is,
but wanted to check.

section 5.3.3.1

- error_info is a UTF-8 string unless otherwise stated. Is this
intended for human consumption or not? If so, then how are language
issues to be handled?

- I'm not clear as to whether the error_info for the various
error_code values is expected to be as described here. For example, if
the error is Error_Forbidden, does the description of that imply
something about what goes into error_info or not?

- typo: Error_Data_Too_old is repeated.

section 5.3.4:

- might be no harm to also say that the NodeID in H(NodeID ||
certificate) MUST be in network byte order? Saying "simple raw bytes"
could cause endian-issues there.

- This says that "receiving nodes" MUST verify the signature. Earlier
it said that nodes just need to check formatting (in 5.1). That seems
to be a conflict.  See also discuss point (2).

- I don't get how the first additional check works if the response has
a via - I thought that that meant that the nodes on the path for the
response didn't need state? If so, then how does the verifier here
know who originated the request to which this is a response?

- The 2nd additional check is a bit unclear for me. It says that
response-sender-node-ID MUST be as close or closer to the resource-id
in the *requesting node's* neighbour table. How does a verifier in the
middle of the path get to see the requesting node's neighbour table?

section 5.4.1:

- Has anyone specified a topology plugin other than the MTI one from
here? I'm wondering if the list here is really complete and doable.
(It'd be easy to get this wrong.)

section 5.4.2.1:

- Which error SHOULD nodes sent if they cannot form connections?

section 5.6.3.1:

- Is the "no more aggressive than TFRC" sentence here clear?

section 6.1:

- given that the StoredDataValue can be up to 4GB would it be better
to put the SignerIdentity before that in the signature input? That
might help the verifier go quicker in the case of LARGE data values I
guess.

section 6.2:

- Is 2^32-1 octets really expected to be supported here? Might there
be a case for distinguishing small (say up to N KB) from larger data
values?  (Just checking)

section 6.2.3:

- it'd be no harm to say what you get when a non-existent dictionary
key is used in a query, as you did in 6.2.2 for arrays.

section 6.4.1.1:

- this introduces the "anonymous" and "none" values for
SignatureAndHashAlgorithm on page 88.  That really needs to be
introduced where signing is first discussed and you need to say when
its allowed to be used and for what. (In this part you just say it
cannot be used.)

section 6.4.1.3:

- "(unlike previous versions)" - if there's nothing you can reference
then I'd suggest taking this out - it might have been useful for the
WG but might just confuse the RFC reader.

section 6.4.2.1:

- I don't get the last sentence - how does the requester ask for the
user's cert? And should that say owner's cert? (That may be just due
to how long it's taken me to read this, at multiple sittings;-)

section 8:

- You should probably add a reference for the "private address range"
and think about whether or not the putative new private allocation
counts there too. (It may be that getting this document finished takes
long enough that that process is done.)

section 9.7:

- You RECOMMEND that a peer maintain O(log(N)) things in the neighbour
set. I'm not clear how the peer knows the value of N there?

section 10.1

- This is not right! Why not use a real  in the example?
If the example could be verified that'd help coders.

- You might say is ascii-hex values can be mixed case or not. Be a
shame to fall over because of that and coders might make different
assumptions.

- Why are we not using XMLDSIG for the signatures here?  (Only
kidding:-)

section 10.2

- s/by determines/by determining/

- Isn't RFC6125 a better reference here than 2818?

- Does this practically mean that overlays should be named using DNS
names? If so, saying that early would be good rather than on p124.

- s/such an/such as an/

section 10.3:

- Does the enrollment server web server cert have to have any
relationship with the configuration?  I don't think that's needed, but
am not sure. It'd be good to say either way though.

- Using HTTP errors is fairly coarse grained. In particular don't you
want to have a way to say "everything's fine but you asked for too
many nodeids"? If there's a good HTTP error for that then calling it
out would be good. Just a bare 4xx for username/password errors is
fine though.

section 12:

- Do you need to reference the TLS re-negotiation bug RFC?  Would it
have a bad impact here? (Not sure.)

section 13.5

- I don't get why you have two SIP entries there. It'd be nice to
know.

[Ballot comment]
- The document seems to be schizophrenic about Head of Line blocking.  The section 6.5.1.6 text on why TCP is not a desirable Overlay Link Protocol notes Head of Line blocking as the primary reason to prefer another protocol, yet the stop and wait algorithm in 6.6.3.1 for use over DTLS, says that only one message can be unacknowledged at a time, so it's unclear how this avoid Head of Line blocking issues (if at all).  It seems like you seay HoL issues are worth avoiding, and then define operation only over transports with HoL issues (TCP and the DTLS-based ones).

[Ballot discuss]
I have updated my Discuss for revision -22 of the document.

Very good progress. All I am left with is our discussion of manageability. In email we had...

>>> Section 3 gives some good input to management although I think the
>>> section is misnamed because a large chunk of the text is about how
>>> the network operates rather than how it is managed.
>>
>> It's about how the network is maintained. It's a bit overloaded,
>> but this is the term the WG chose and I don't think we really
>> have a better term.
>
> Well, who am I to question the semantics agreed by the WG?
>
> It is not important except for how it plays into the following...
>
>>> I think you need to take a look at RFC 5706 for gidance on other
>>> management concepts you should include. I am personally interested in
>>> what OAM mechanisms you propose. (Yes, I do see section 5.5.3, but I
>>> don't believe this is significant OAM in a layer network.)
>>>
>>> >> In email I clarified this...
>>> >>
>>> >> | forward pointers to other I-Ds might help a lot.
>>> >> | In general, however, if you are building such a comprehensive new
>>> >> | architecture, I would ask you to include the architectural description
>>> >> | of OAM in this document and only punt the protocol details to other
>>> >> | documents.
>>
>> This is fundamentally a self-organizing network with minimal central
>> management. It might be nice to have a central management
>> architecture, and the WG consensus was that one was not needed, and I
>> don't believe it's appropriate to block advancement of this document
>> pending that existing.
>
> I don't think that I asked for a central management architecture.
>
> Self-organising networks are fine.
>
> How do they detect faults and repair themselves?
> How does the user work out why things aren't working?
> How does the service provider (careful to not say network operator) work
> out what is going on, what is broken, where the congestion is?
>
> Over the years, there has been a lot of breast-beating about the problems
> introduced by not thinking about OAM during the design of new protocols
> and network architectures. This has resulted in strong advice and guidance
> that this should be addressed at least at the requirements and architecture
> level during protocol development, and OAM protocol work should ideally
> be started in parallel to the main protocol development.
>
> IMHO it is perfectly valid to hold up this document to discuss these issues
> (please note that Dan Romascanu as Ops AD at the time also placed a
> Discuss on this point). Since there are a number of other topics being
> discussed for the document, we can pipeline this issue and it need not
> "block" the document at all.

---

And a note that there is agreement to send the updated document back to the WG for sign-off before advancing to publication.

[Ballot comment]
Comment also updated for -22. Many points remain for consideration.

---

Section 1.2

  Topology Plugin:  The Topology Plugin is responsible for implementing
      the specific overlay algorithm being used.  It uses the Message
      Transport component to send and receive overlay management
      messages, to the Storage component to manage data replication, and
      directly to the Forwarding Layer to control hop-by-hop message
      forwarding.  This component closely parallels conventional routing
      algorithms, but is more tightly coupled to the Forwarding Layer
      because there is no single "routing table" equivalent used by all
      overlay algorithms.

Garbled English, I think. Try...

  Topology Plugin:  The Topology Plugin is responsible for implementing
      the specific overlay algorithm being used.  It uses the Message
      Transport component to send and receive overlay management
      messages, the Storage component to manage data replication, and
      the Forwarding Layer to control hop-by-hop message forwarding.
      This component closely parallels conventional routing algorithms,
      but is more tightly coupled to the Forwarding Layer because there
      is no single "routing table" equivalent used by all overlay
      algorithms.

That is, the Topology Plugin does not use the Message Transport
component to communicate with the Storage component (or if it does, your
figure is broken).

I also think I object to "closely parallels conventional routing
algorithms". Unless I mistake it, the Topology Plugin has two functions:
- constructing the local forwarding instructions
- selecting the operational topology (i.e. creating links by sending
  overlay management messages).

Personally, I think your work would be improved by separating topology
management and forwarding determination within your architecture.

---

The figure in Section 1.2 is missing "Usage Layer" and "Overlay Link   
Layer" both of which are described in the text.

---

I think (somewhat understandably) your terminology keeps getting
snarled. The problem is that if you reuse terms (like transport) in
the overlay, then you can get pretty confused when you talk about
the underlying infrastructure. You also have to get unconfused about
the use of the word "transport" in OSI model, and "transport" in the

Thus...

  Overlay Link Layer:  Responsible for actually transporting traffic
      directly between nodes.  Each such protocol includes the
      appropriate provisions for per-hop framing or hop-by-hop ACKs
      required by unreliable transports.  TLS [RFC5246] and DTLS
      [RFC4347] are the currently defined "link layer" protocols used by
      RELOAD for hop-by-hop communication.  New protocols can be
      defined, as described in Section 5.6.1 and Section 10.1.  As this
      document defines only TLS and DTLS, we use those terms throughout
      the remainder of the document with the understanding that some
      future specification may add new overlay link layers.

The link layer doesn't transport traffic in the sense you have used
"Message Transport". (It does do transort in the sense of a transport
layered network, but I doubt you want to get into this confusion.

Maybe s/transporting/delivering/

Additionally...

"Each such protocol" - you have not mentioned protocols thus far.

"hop-by-hop ACKs required by unreliable transports" - don't the ACKs
(in the overlay link layer) make the link reliable?

---

The figure at the end of 1.2 is really helpful. I wonder if you should
change "real Internet" because (I think) your work is part of the
Internet.

I also think that your construct is arbitrarily nestable.

It might be worth noting that you could run directly over a physical
link using an appropriate encapsulation. That is, you do not need to
run over calssic transport protocol spanning the Internet.

---

The statement in 1.2.2 that

  The Message Transport component provides a generic message routing
  service for the overlay.
                                           
is a highly confusing use of "routing". Is that what you meant to say?

A reference for KBR would help.

---

1.2.5

  This layer also utilizes a framing header to encapsulate messages as
  they are forwarding along each hop.

s/forwarding/forwarded/

---

Section 2.

Just for my clarity: "peers" are not necessarily adjacent in the overlay
network? They are just the collection of nodes participating in an
overlay instance?

---

Section 2

  Kind:  A kind defines a particular type of data that can be stored in
      the overlay.  Applications define new Kinds to store the data they
      use.  Each Kind is identified with a unique integer called a
      Kind-ID.

Please decide whether "Kind" or "kind" and aply to this paragraph and to
the whole of the document.

---

Section 2

  Resource Name:  The potentially human readable name

Is "potentially human readable" helpful?

---

Section 2

Are you sure that "Resource" and "Resource Name" are not circular
definitions?

Resource is an object associated with a string identifier.
Resource Name is a name by which a resource is identified.

But what is a resource in concrete terms?

---

Section 2

There is some loose language around names and identifiers.

  Resource:  An object or group of objects associated with a string
      identifier.  See "Resource Name"

  Resource Name:  The potentially human readable name by which a
      resource is identified.

  Resource-ID:  A value that identifies some resources

---

Section 2

Connection Table and Routing Table talk about Attach and Update way
before they are discussed in the document. Would it be possible to
phrase these definitions in slightly more abstract language?

---

Section 2

  Routing Table:  The set of peers which a node can use to route
      overlay messages.

Would it be helpful to state that the Routing Table contains "next hop
peers"?

Is this definition actually all there is to say about the Routing Table?
It is just a list of peers that can be used to reach other non-connected
peers? There is no information in the Routing Table about which peers
can be reached through which non-connected peers?

---

Section 2

  Destination List:  A list of IDs through which a message is to be
      routed.  A single Node-ID is a trivial form of destination list.

I think s/list of IDs/list of Node-IDs/

Can you clarify whether the list is complete? Is the list reduced hop
by hop, or does it remain as a history? Does it include the source /
node in hand? Does it include the destination?

---

Section 2

  Usage:  A usage is an application that wishes to use the overlay for
      some purpose.  Each application wishing to use the overlay defines
      a set of data kinds that it wishes to use.  The SIP usage defines
      the location data kind.

The word "application" causes ambiguity.
The Microsoft Word running on my PC is an application instance.
Microsoft Word is an application.
"Word processors" is also an application (maybe Application Type?)

---

Section 3.1

  o  To determine its position in the overlay topology when the overlay
      is structured.

s/when/if/  ?

---

Section 3.1

  The general principle here is that the security mechanisms (TLS and
  message signatures) are always used, even if the certificates are
  self-signed.

Is discussion of TLS in scope here? TLS would be in the data link layer
in your architecture, wouldn't it? Or are you saying that TLS is used
in the Message Transport component?

---

Section 3.2

  From the perspective of a peer, a client is simply a node
  which has not yet sent any Updates or Joins.

Can you rephrase this in the abstract because we have not yet been told
what an Update or a Join is?

---

Section 3.2.1

      forming a direct connections

s/connections/conneciton/

---

Section 3.2.1

  o  Establish a connection with an arbitrary peer in the overlay
      (perhaps based on network proximity or an inability to establish a
      direct connection with the responsible peer).

The term "responsible peer" has not been defined. I suspect you mean the
term in the context of Section 1.1...

  Peers are responsible for
  storing the data associated with some set of addresses as determined
  by their Node-ID.

---

Section 3.2.2

  A node may act as a client simply because it does not have the
  resources or even an implementation of the topology plugin required
  to act as a peer in the overlay.

"Resource" is a term with a very specific meaning in this document. You
might want to use a different term here.

---

3.2.2

  calculating the Resource-ID
  requires an implementation of the appropriate algorithm for the
  overlay.

This discussion of an algorithm (and, indeed, calculating a Resource-ID)
is novel. Isn't it enough to say that a client must sufficiently
understand the nature of the overlay network to be able to determine the
correct Resource-IDs to use?

---

Section 3.3

  Low state:    RELOAD's routing algorithms must not require
      significant state to be stored on intermediate peers.

"Significant" is subjective. What does this requirement mean?

---

Section 3.3
                                           
The mechanism described as "iterative routing" is very fine. But the
name is confusing. This is just route query, or route inspection?
I guess that to operate the mechanism you iteratively query the hops
along the path, in order to determine the explicit route: does that
make it "iterative routing" or just an iterative query?

---

Section 3.4

  Say that peer A wishes to form a direct connection to peer B.

The thing that triggers it to "wish" is interesting and might benefit
from a cross-reference to the appropriate part of this I-D.

I would note that
  In general, a peer needs to maintain connections to all of the peers
  near it in the Overlay Instance and to enough other peers to have
  efficient routing (the details depend on the specific overlay).
is tautology. "Near" is a trocky word! You probably mean "near in the
underlying Internet topology", but unless you are going to describe a
way of knowing that (ALTO?) you can't leverage it. On the other hand,
"near" in the overlay network means that there are connections (hence
the tautology).

Also:
  However, a peer should try to maintain the
  specified link set and if it detects that it has fewer direct
  connections, should form more as required.
I don't find information about how that link set is specified.

---

Section 5.1.2

  If neither of the other three cases applies, then the peer MUST

I think there are only two other cases. I.e. total of three for which
this is the second.

---

Section 5.1.2

  and which is likely to be responsible for the first entry
  on the destination list

I don't find that very helpful. In the fully connected networks, this
may be likely. In the longer paths (such as in the examples in this
document) or when Destination List is not a complete list, I don't
think "likely" applies.

---

Section 5.1.2

  None of the above mechanisms are required for responses, since there
  is no need to ensure that subsequent requests follow the same path.

Fixing the grammar and swapping the order to avoid some ambiguity...

  There is no requirement to ensure that a request issued after the
  receipt of a response follows the same path as the response. As a
  consequence, there is no reuirement to use either of the mechanisms
  described above (via list or state retention) when processing a
  response message.

---

Section 5.3.2.1

I don't think it is helpful to mix and match hex and decimal values in
this section.

---

Section 5.4

  As discussed in previous sections, RELOAD does not itself implement
  any overlay topology.  Rather, it relies on Topology Plugins, which
  allow a variety of overlay algorithms to be used while maintaining
  the same RELOAD core.

FWIW, I think RELOAD *does* implement the overlay topology. But it is
the Topology Plugin that configures/determines the topology to be
implemented.

[Ballot comment]
Page 38 - Section 5.2.1 - might be worth calling out that the sending node will be doing both e2e and hopbyhop retransmissions

Page 48 - Section 5.3.3 - should note 0x8000-0xfffe are reserved

Page 82 - Section 6 - Can you find a different word than "unpartitioning" (or define it)? - it only occurs once in the document.

Page 107 - the formula at the end of 9.5 has unbalanced parentheses

Page 112 - In the implementer note in 9.7.4.3, can you point to references to get the implementer started?

Section 3 as revised contains a lot of normative keywords. I thought the intent was to keep those out of the overview sections.

[Ballot discuss]
This document being the principal specification that defines a new protocol I was expecting to find information concerning operational and manageability considerations. Some information was added following my initial DISCUSS describing in more details the interaction with the configuration server and the error codes.  However this is not sufficient, and I am still missing information about how the protocol will be deployed in existing networks, what is the impact on traffic, requirements from hosts, routers, midcom devices (if any), what is the operational model, are there any defaults for initial configuration, how is performance monitored. A separate document (draft-ietf-p2psip-diagnostics) defines extensions to the base protocol for diagnostic purposes, and this is fine. However that document is not referred here

[Ballot discuss]
This document being the principal specification that defines a new protocol I was expecting to find information concerning operational and manageability considerations. Some information was added following my initial DISCUSS describing in mode detailed the information and interaction with the configuration server and error codes.  However this is not sufficient, and I am still missing information about how the protocol will be deployed in existing networks, what is the impact on traffic and requirements from hosts, routers, midcom devices (if any), what is the operational model, any are there any defaults for initial configuration, how is performance monitored. A separate document (draft-ietf-p2psip-diagnostics) defines extensions to the base protocol for diagnostic purposes, and this is fine. However that document is not referred here

[Ballot comment]
I have not examined revision -20 to see whether my Comments have been addressed. I trust the authors, shepherd and responsible AD to pick up those Comments that needed work.

===

DHT is used several times before it is expanded.

---

Section 1.2

  Topology Plugin:  The Topology Plugin is responsible for implementing
      the specific overlay algorithm being used.  It uses the Message
      Transport component to send and receive overlay management
      messages, to the Storage component to manage data replication, and
      directly to the Forwarding Layer to control hop-by-hop message
      forwarding.  This component closely parallels conventional routing
      algorithms, but is more tightly coupled to the Forwarding Layer
      because there is no single "routing table" equivalent used by all
      overlay algorithms.

Garbled English, I think. Try...

  Topology Plugin:  The Topology Plugin is responsible for implementing
      the specific overlay algorithm being used.  It uses the Message
      Transport component to send and receive overlay management
      messages, the Storage component to manage data replication, and
      the Forwarding Layer to control hop-by-hop message forwarding.
      This component closely parallels conventional routing algorithms,
      but is more tightly coupled to the Forwarding Layer because there
      is no single "routing table" equivalent used by all overlay
      algorithms.

That is, the Topology Plugin does not use the Message Transport
component to communicate with the Storage component (or if it does, your
figure is broken).

I also think I object to "closely parallels conventional routing
algorithms". Unless I mistake it, the Topology Plugin has two functions:
- constructing the local forwarding instructions
- selecting the operational topology (i.e. creating links by sending
  overlay management messages).

Personally, I think your work would be improved by separating topology
management and forwarding determination within your architecture.

---

The figure in Section 1.2 is missing "Usage Layer" and "Overlay Link   
Layer" both of which are described in the text.

---

I think (somewhat understandably) your terminology keeps getting
snarled. The problem is that if you reuse terms (like transport) in
the overlay, then you can get pretty confused when you talk about
the underlying infrastructure. You also have to get uncinfused about
the use of the word "transport" in OSI model, and "transport" in the

Thus...

  Overlay Link Layer:  Responsible for actually transporting traffic
      directly between nodes.  Each such protocol includes the
      appropriate provisions for per-hop framing or hop-by-hop ACKs
      required by unreliable transports.  TLS [RFC5246] and DTLS
      [RFC4347] are the currently defined "link layer" protocols used by
      RELOAD for hop-by-hop communication.  New protocols can be
      defined, as described in Section 5.6.1 and Section 10.1.  As this
      document defines only TLS and DTLS, we use those terms throughout
      the remainder of the document with the understanding that some
      future specification may add new overlay link layers.

The link layer doesn't transport traffic in the sense you have used
"Message Transport". (It does do transort in t sense of a transport
layered network, but I doubt you want to get into this confusion.

Maybe s/transporting/delivering/

Additionally...

"Each such protocol" - you have not mentioned protocols thus far.

"hop-by-hop ACKs required by unreliable transports" - don't the ACKs
(in the overlay link layer) make the link reliable?

---

The figure at the end of 1.2 is really helpful. I wonder if you should
change "real Internet" because (I think) your work is part of the
Internet.

I also think that your construct is arbitrarily nestable.

It might be worth noting that you could run directly over a physical
link using an appropriate encapsulation. That is, you do not need to
run over calssic transport protocol spanning the Internet.

---

The statement in 1.2.2 that

  The Message Transport component provides a generic message routing
  service for the overlay.
                                           
is a highly confusing use of "routing". Is that what you meant to say?

A reference for KBR would help.

---

1.2.5

  This layer also utilizes a framing header to encapsulate messages as
  they are forwarding along each hop.

s/forwarding/forwarded/

---

Section 2.

Just for my clarity: "peers" are not necessarily adjacent in the overlay
network? They are just the collection of nodes participating in an
overlay instance?

---

Section 2

  Kind:  A kind defines a particular type of data that can be stored in
      the overlay.  Applications define new Kinds to store the data they
      use.  Each Kind is identified with a unique integer called a
      Kind-ID.

Please decide whether "Kind" or "kind" and aply to this paragraph and to
the whole of the document.

---

Section 2

  Resource Name:  The potentially human readable name

Is "potentially human readable" helpful?

---

Section 2

Are you sure that "Resource" and "Resource Name" are not circular
definitions?

Resource is an object associated with a string identifier.
Resource Name is a name by which a resource is identified.

But what is a resource in concrete terms?

---

Section 2

There is some loose language around names and identifiers.

  Resource:  An object or group of objects associated with a string
      identifier.  See "Resource Name"

  Resource Name:  The potentially human readable name by which a
      resource is identified.

  Resource-ID:  A value that identifies some resources

---

Section 2

Connection Table and Routing Table talk about Attach and Update way
before they are discussed in the document. Would it be possible to
phrase these definitions in slightly more abstract language?

---

Section 2

  Routing Table:  The set of peers which a node can use to route
      overlay messages.

Would it be helpful to state that the Routing Table contains "next hop
peers"?

Is this definition actually all there is to say about the Routing Table?
It is just a list of peers that can be used to reach other non-connected
peers? There is no information in the Routing Table about which peers
can be reached through which non-connected peers?

---

Section 2

  Destination List:  A list of IDs through which a message is to be
      routed.  A single Node-ID is a trivial form of destination list.

I think s/list of IDs/list of Node-IDs/

Can you clarify whether the list is complete? Is the list reduced hop
by hop, or does it remain as a history? Does it include the source /
node in hand? Does it include the destination?

---

Section 2

  Usage:  A usage is an application that wishes to use the overlay for
      some purpose.  Each application wishing to use the overlay defines
      a set of data kinds that it wishes to use.  The SIP usage defines
      the location data kind.

The word "application" causes ambiguity.
The Microsoft Word running on my PC is an application instance.
Microsoft Word is an application.
"Word processors" is also an application (maybe Application Type?)

---

Section 3.1

  o  To determine its position in the overlay topology when the overlay
      is structured.

s/when/if/  ?

---

Section 3.1

  The general principle here is that the security mechanisms (TLS and
  message signatures) are always used, even if the certificates are
  self-signed.

Is discussion of TLS in scope here? TLS would be in the data link layer
in your architecture, wouldn't it? Or are you saying that TLS is used
in the Message Transport component?

---

Section 3.2

  From the perspective of a peer, a client is simply a node
  which has not yet sent any Updates or Joins.

Can you rephrase this in the abstract because we have not yet been told
what an Update or a Join is?

---

Section 3.2.1

      forming a direct connections

s/connections/conneciton/

---

Section 3.2.1

  o  Establish a connection with an arbitrary peer in the overlay
      (perhaps based on network proximity or an inability to establish a
      direct connection with the responsible peer).

The term "responsible peer" has not been defined. I suspect you mean the
term in the context of Section 1.1...

  Peers are responsible for
  storing the data associated with some set of addresses as determined
  by their Node-ID.

---

Section 3.2.2

  A node may act as a client simply because it does not have the
  resources or even an implementation of the topology plugin required
  to act as a peer in the overlay.

"Resource" is a term with a very specific meaning in this document. You
might want to use a different term here.

---

3.2.2

  calculating the Resource-ID
  requires an implementation of the appropriate algorithm for the
  overlay.

This discussion of an algorithm (and, indeed, calculating a Resource-ID)
is novel. Isn't it enough to say that a client must sufficiently
understand the nature of the overlay network to be able to determine the
correct Resource-IDs to use?

---

Section 3.3

  Low state:    RELOAD's routing algorithms must not require
      significant state to be stored on intermediate peers.

"Significant" is subjective. What does this requirement mean?

---

Section 3.3
                                           
The mechanism described as "iterative routing" is very fine. But the
name is confusing. This is just route query, or route inspection?
I guess that to operate the mechanism you iteratively query the hops
along the path, in order to determine the explicit route: does that
make it "iterative routing" or just an iterative query?

---

Section 3.4

  Say that peer A wishes to form a direct connection to peer B.

The thing that triggers it to "wish" is interesting and might benefit
from a cross-reference to the appropriate part of this I-D.

I would note that
  In general, a peer needs to maintain connections to all of the peers
  near it in the Overlay Instance and to enough other peers to have
  efficient routing (the details depend on the specific overlay).
is tautology. "Near" is a trocky word! You probably mean "near in the
underlying Internet topology", but unless you are going to describe a
way of knowing that (ALTO?) you can't leverage it. On the other hand,
"near" in the overlay network means that there are connections (hence
the tautology).

Also:
  However, a peer should try to maintain the
  specified link set and if it detects that it has fewer direct
  connections, should form more as required.
I don't find information about how that link set is specified.

---

Section 5.1.2

  If neither of the other three cases applies, then the peer MUST

I think there are only two other cases. I.e. total of three for which
this is the second.

---

Section 5.1.2

  and which is likely to be responsible for the first entry
  on the destination list

I don't find that very helpful. In the fully connected networks, this
may be likely. In the longer paths (such as in the examples in this
document) or when Destination List is not a complete list, I don't
think "likely" applies.

---

Section 5.1.2

  None of the above mechanisms are required for responses, since there
  is no need to ensure that subsequent requests follow the same path.

Fixing the grammar and swapping the order to avoid some ambiguity...

  There is no requirement to ensure that a request issued after the
  receipt of a response follows the same path as the response. As a
  consequence, there is no reuirement to use either of the mechanisms
  described above (via list or state retention) when processing a
  response message.

---

Section 5.3.2.1

I don't think it is helpful to mix and match hex and decimal values in
this section.

---

Section 5.4

  As discussed in previous sections, RELOAD does not itself implement
  any overlay topology.  Rather, it relies on Topology Plugins, which
  allow a variety of overlay algorithms to be used while maintaining
  the same RELOAD core.

FWIW, I think RELOAD *does* implement the overlay topology. But it is
the Topology Plugin that configures/determines the topology to be
implemented.

[Ballot discuss]
I have updated my Discuss for revision -20 of the document by deleting
points that have been addressed, and annotating with ">>"

Thanks for the work so far.

===

I am convinced that this document will prove to be extremely important
for the future of the Internet. That maybe makes the bar a little higher
and means that I would like to know the spec is really good. My baseline
is that the spec needs to reliably produce interoperable implementations
and, of course, work.

I've limited my focus to the parts concerned with routing.

Overall, the number of comments I have generated worries me. In part
this is because you have written a large document in an area that is
new to me. But I am concerned that this means that the document really
would benefit from significant attention. My issue is that with the
number of questions I am raising I am not able to provide a decent
technical review, and implementers may find this document really hard
work.

I hope that my comments will help improve the document.
         
---

Introduction 

  to efficiently route messages

"Efficiency" in routing is a concept that may need qualifying. Maybe
you mean select an optimal path. But even that doesn't help much without
some explanation of the paradigm.

>> Discussions via email indicated this "fluff" would be removed.

---

I do not believe that this document (and specifically section 9)
contains information to implement chord-reload without reference to
[chord]. That makes [chord] a normative reference.

However, rather than that change, I would prefer this document to be
self-contained, and to include a full implementable description of
chord-reload.

>> In email exchange I made some specific suggestions. These
>> do not appear to have been incorporated...
>>
>> |  ...issues include:
>> | - Section 9 starts by listing the differences from [chord]. This can't be
>> |    useful unless I have read [chord]. Maybe move to 9.10 and note
>> |    that it is provided for information only?
>> | - What is a finger table? Maybe rewrite this section using terminology
>> |    from this document and not terminology from [chord]?
>> | - Ditto neighbor table
>> | - What is a DHT ring?
>> | - Does it matter to the results of the various algorithms how the data
>> |  is stored? The efficiency of lookup is very interesting, but that is
>> |  technically an implementation detail.

---

Section 3 gives some good input to management although I think the
section is misnamed because a large chunk of the text is about how
the network operates rather than how it is managed.

I think you need to take a look at RFC 5706 for gidance on other
management concepts you should include. I am personally interested in
what OAM mechanisms you propose. (Yes, I do see section 5.5.3, but I
don't believe this is significant OAM in a layer network.)

>> In email I clarified this...
>>
>> | forward pointers to other I-Ds might help a lot.
>> | In general, however, if you are building such a comprehensive new architecture,
>> | I would ask you to include the architectural description of OAM in this document
>> | and only punt the protocol details to other documents.

---

Section 3.3

I am surprised that the sending-hop node is added to the Via List (in
the figure) by the receiving-hop node. This is not optimal and might be
"entertaining" on multi-access links if such could ever exist.

I would have expected that the sending-hop would add itself prior to
sending the message. This is what other technologies do.

>> In email I expanded...
>>
>> | In this mode, the receiver must process each message in the context
>> | of the link on which it arrived. Of course this is possible, but it
>> | complicates an implementation. The sender knows its own identity
>> | and can add it easily. The receiver has to take the information about
>> | the incoming link and look up the identity of the remote link end (not
>> | a huge burden, but...)
>> |
>> | Who is to say that P2P links today will not become something more
>> | exotic tomorrow?

---

Section 3.5.1

I am having trouble understanding how all nodes in an Overlay Instance
arrange to use the same Overlay Algorithm (which I believe is a
requirement). 

Maybe there is a parameter on a Join?
Could this section explain?

>> The new text is a help to explaining the intention.
>>
>> What is now not clear is what happens if there is a
>> misconfiguration. How do two nodes believing they are
>> in the same overlay communicate correctly if they have
>> been configured with different algorithms?

---

Section 3.6.1

Should the figure in 1.2 show a component for "Bootstrap and
Configuration"? My issue here is that DNS lives below the Overlay Link
Service Boundary line. Similarly, HTTP is below the line. In some ways
the uses of these services is analagous to the use of ARP and DHCP in
bottstrapping routers and hosts. Can you show how these services fit
in on the diagrams in 1.2?

>> I don't see any change to address my point. While I appreciate that
>> the figure might be too crowded, my point (as explained in email)
>> was that I have to read as far as 3.6.1 before discovering the
>> missing component/interface.
>>
>> A solution would be to add text close to the figure.

---

Section 5.3.2

  version:  The version of the RELOAD protocol being used.  This is a
      fixed point integer between 0.1 and 25.4.  This document describes
      version 0.1, with a value of 0x01. [[ Note to RFC Editor:  Please
      update this to version 1.0 with value of 0x0a and remove this
      note. ]]

Can you explain why this document has a value in the version field other
than the value that will be in the RFC? Obviously no-one has implemented
and deployed a pre-standard version.

>> I suggested alternative text by email
>>
>> |    version:  The version of the RELOAD protocol being used.  This is a
>> |    fixed point integer between 1.0 and 25.4.  This document describes
>> |    version 1.0 with value of 0x0a.  Messages carrying unrecognized
>> |    version values MUST be

---

>> New point
>>
>> Section 5.6.3 seems to have been rewritten with the inclusion of some
>> new RFC 2119 language (amongst other changes). Has this change
>> received WG last call?

[Ballot discuss]
[UPDATED based on -20.]

I'd like to talk about several points that I haven't seen mentioned in
other reviews.

1. Section 1.3 appears to couple issuance of certificates and assignment
of Node-IDs (in most cases):

  RELOAD's security model is based on each node having one or more
  public key certificates.  In general, these certificates will be
  assigned by a central server which also assigns Node-IDs, although
  self-signed certificates can be used in closed networks.

What is the reason for this coupling? Does it have security
implications? At the least, a forward reference to later sections
(e.g., 3.1) might help.

2. Does the use of list compression (Section 5.1.2) and private IDs
(Section 5.1.3) prevent an intermediate node from routing return messages
if its neighbor goes offline? In your example, if E has a destination
list of (D, I) but D goes offline, then E won't be able to unpack the
private ID "I" to recover the via list "(A, B, C)".

3. In Section 10.1, the format of the 'expiration' attribute is not
fully specified (e.g., are timezone offsets allowed or must the datetime
be UTC?). UPDATE: I'm sorry if my comment was unclear, but I think
it would be good to cite RFC 3339 here; when doing so, please make
sure that you document all the details about various options, such as
use of non-UTC time zones and fractional seconds.

4. Addressed in -20.

5. Addressed in -20.

[Ballot comment]
DHT is used several times before it is expanded.

---

Section 1.2

  Topology Plugin:  The Topology Plugin is responsible for implementing
      the specific overlay algorithm being used.  It uses the Message
      Transport component to send and receive overlay management
      messages, to the Storage component to manage data replication, and
      directly to the Forwarding Layer to control hop-by-hop message
      forwarding.  This component closely parallels conventional routing
      algorithms, but is more tightly coupled to the Forwarding Layer
      because there is no single "routing table" equivalent used by all
      overlay algorithms.

Garbled English, I think. Try...

  Topology Plugin:  The Topology Plugin is responsible for implementing
      the specific overlay algorithm being used.  It uses the Message
      Transport component to send and receive overlay management
      messages, the Storage component to manage data replication, and
      the Forwarding Layer to control hop-by-hop message forwarding.
      This component closely parallels conventional routing algorithms,
      but is more tightly coupled to the Forwarding Layer because there
      is no single "routing table" equivalent used by all overlay
      algorithms.

That is, the Topology Plugin does not use the Message Transport
component to communicate with the Storage component (or if it does, your
figure is broken).

I also think I object to "closely parallels conventional routing
algorithms". Unless I mistake it, the Topology Plugin has two functions:
- constructing the local forwarding instructions
- selecting the operational topology (i.e. creating links by sending
  overlay management messages).

Personally, I think your work would be improved by separating topology
management and forwarding determination within your architecture.

---

The figure in Section 1.2 is missing "Usage Layer" and "Overlay Link   
Layer" both of which are described in the text.

---

I think (somewhat understandably) your terminology keeps getting
snarled. The problem is that if you reuse terms (like transport) in
the overlay, then you can get pretty confused when you talk about
the underlying infrastructure. You also have to get uncinfused about
the use of the word "transport" in OSI model, and "transport" in the

Thus...

  Overlay Link Layer:  Responsible for actually transporting traffic
      directly between nodes.  Each such protocol includes the
      appropriate provisions for per-hop framing or hop-by-hop ACKs
      required by unreliable transports.  TLS [RFC5246] and DTLS
      [RFC4347] are the currently defined "link layer" protocols used by
      RELOAD for hop-by-hop communication.  New protocols can be
      defined, as described in Section 5.6.1 and Section 10.1.  As this
      document defines only TLS and DTLS, we use those terms throughout
      the remainder of the document with the understanding that some
      future specification may add new overlay link layers.

The link layer doesn't transport traffic in the sense you have used
"Message Transport". (It does do transort in t sense of a transport
layered network, but I doubt you want to get into this confusion.

Maybe s/transporting/delivering/

Additionally...

"Each such protocol" - you have not mentioned protocols thus far.

"hop-by-hop ACKs required by unreliable transports" - don't the ACKs
(in the overlay link layer) make the link reliable?

---

The figure at the end of 1.2 is really helpful. I wonder if you should
change "real Internet" because (I think) your work is part of the
Internet.

I also think that your construct is arbitrarily nestable.

It might be worth noting that you could run directly over a physical
link using an appropriate encapsulation. That is, you do not need to
run over calssic transport protocol spanning the Internet.

---

The statement in 1.2.2 that

  The Message Transport component provides a generic message routing
  service for the overlay.
                                           
is a highly confusing use of "routing". Is that what you meant to say?

A reference for KBR would help.

---

1.2.5

  This layer also utilizes a framing header to encapsulate messages as
  they are forwarding along each hop.

s/forwarding/forwarded/

---

Section 2.

Just for my clarity: "peers" are not necessarily adjacent in the overlay
network? They are just the collection of nodes participating in an
overlay instance?

---

Section 2

  Kind:  A kind defines a particular type of data that can be stored in
      the overlay.  Applications define new Kinds to store the data they
      use.  Each Kind is identified with a unique integer called a
      Kind-ID.

Please decide whether "Kind" or "kind" and aply to this paragraph and to
the whole of the document.

---

Section 2

  Resource Name:  The potentially human readable name

Is "potentially human readable" helpful?

---

Section 2

Are you sure that "Resource" and "Resource Name" are not circular
definitions?

Resource is an object associated with a string identifier.
Resource Name is a name by which a resource is identified.

But what is a resource in concrete terms?

---

Section 2

There is some loose language around names and identifiers.

  Resource:  An object or group of objects associated with a string
      identifier.  See "Resource Name"

  Resource Name:  The potentially human readable name by which a
      resource is identified.

  Resource-ID:  A value that identifies some resources

---

Section 2

Connection Table and Routing Table talk about Attach and Update way
before they are discussed in the document. Would it be possible to
phrase these definitions in slightly more abstract language?

---

Section 2

  Routing Table:  The set of peers which a node can use to route
      overlay messages.

Would it be helpful to state that the Routing Table contains "next hop
peers"?

Is this definition actually all there is to say about the Routing Table?
It is just a list of peers that can be used to reach other non-connected
peers? There is no information in the Routing Table about which peers
can be reached through which non-connected peers?

---

Section 2

  Destination List:  A list of IDs through which a message is to be
      routed.  A single Node-ID is a trivial form of destination list.

I think s/list of IDs/list of Node-IDs/

Can you clarify whether the list is complete? Is the list reduced hop
by hop, or does it remain as a history? Does it include the source /
node in hand? Does it include the destination?

---

Section 2

  Usage:  A usage is an application that wishes to use the overlay for
      some purpose.  Each application wishing to use the overlay defines
      a set of data kinds that it wishes to use.  The SIP usage defines
      the location data kind.

The word "application" causes ambiguity.
The Microsoft Word running on my PC is an application instance.
Microsoft Word is an application.
"Word processors" is also an application (maybe Application Type?)

---

Section 3.1

  o  To determine its position in the overlay topology when the overlay
      is structured.

s/when/if/  ?

---

Section 3.1

  The general principle here is that the security mechanisms (TLS and
  message signatures) are always used, even if the certificates are
  self-signed.

Is discussion of TLS in scope here? TLS would be in the data link layer
in your architecture, wouldn't it? Or are you saying that TLS is used
in the Message Transport component?

---

Section 3.2

  From the perspective of a peer, a client is simply a node
  which has not yet sent any Updates or Joins.

Can you rephrase this in the abstract because we have not yet been told
what an Update or a Join is?

---

Section 3.2.1

      forming a direct connections

s/connections/conneciton/

---

Section 3.2.1

  o  Establish a connection with an arbitrary peer in the overlay
      (perhaps based on network proximity or an inability to establish a
      direct connection with the responsible peer).

The term "responsible peer" has not been defined. I suspect you mean the
term in the context of Section 1.1...

  Peers are responsible for
  storing the data associated with some set of addresses as determined
  by their Node-ID.

---

Section 3.2.2

  A node may act as a client simply because it does not have the
  resources or even an implementation of the topology plugin required
  to act as a peer in the overlay.

"Resource" is a term with a very specific meaning in this document. You
might want to use a different term here.

---

3.2.2

  calculating the Resource-ID
  requires an implementation of the appropriate algorithm for the
  overlay.

This discussion of an algorithm (and, indeed, calculating a Resource-ID)
is novel. Isn't it enough to say that a client must sufficiently
understand the nature of the overlay network to be able to determine the
correct Resource-IDs to use?

---

Section 3.3

  Low state:    RELOAD's routing algorithms must not require
      significant state to be stored on intermediate peers.

"Significant" is subjective. What does this requirement mean?

---

Section 3.3
                                           
The mechanism described as "iterative routing" is very fine. But the
name is confusing. This is just route query, or route inspection?
I guess that to operate the mechanism you iteratively query the hops
along the path, in order to determine the explicit route: does that
make it "iterative routing" or just an iterative query?

---

Section 3.4

  Say that peer A wishes to form a direct connection to peer B.

The thing that triggers it to "wish" is interesting and might benefit
from a cross-reference to the appropriate part of this I-D.

I would note that
  In general, a peer needs to maintain connections to all of the peers
  near it in the Overlay Instance and to enough other peers to have
  efficient routing (the details depend on the specific overlay).
is tautology. "Near" is a trocky word! You probably mean "near in the
underlying Internet topology", but unless you are going to describe a
way of knowing that (ALTO?) you can't leverage it. On the other hand,
"near" in the overlay network means that there are connections (hence
the tautology).

Also:
  However, a peer should try to maintain the
  specified link set and if it detects that it has fewer direct
  connections, should form more as required.
I don't find information about how that link set is specified.

---

Section 5.1.2

  If neither of the other three cases applies, then the peer MUST

I think there are only two other cases. I.e. total of three for which
this is the second.

---

Section 5.1.2

  and which is likely to be responsible for the first entry
  on the destination list

I don't find that very helpful. In the fully connected networks, this
may be likely. In the longer paths (such as in the examples in this
document) or when Destination List is not a complete list, I don't
think "likely" applies.

---

Section 5.1.2

  None of the above mechanisms are required for responses, since there
  is no need to ensure that subsequent requests follow the same path.

Fixing the grammar and swapping the order to avoid some ambiguity...

  There is no requirement to ensure that a request issued after the
  receipt of a response follows the same path as the response. As a
  consequence, there is no reuirement to use either of the mechanisms
  described above (via list or state retention) when processing a
  response message.

---

Section 5.3.2.1

I don't think it is helpful to mix and match hex and decimal values in
this section.

---

Section 5.4

  As discussed in previous sections, RELOAD does not itself implement
  any overlay topology.  Rather, it relies on Topology Plugins, which
  allow a variety of overlay algorithms to be used while maintaining
  the same RELOAD core.

FWIW, I think RELOAD *does* implement the overlay topology. But it is
the Topology Plugin that configures/determines the topology to be
implemented.

[Ballot discuss]
I am convinced that this document will prove to be extremely important
for the future of the Internet. That maybe makes the bar a little higher
and means that I would like to know the spec is really good. My baseline
is that the spec needs to reliably produce interoperable implementations
and, of course, work.

I've limited my focus to the parts concerned with routing.

Overall, the number of comments I have generated worries me. In part
this is because you have written a large document in an area that is
new to me. But I am concerned that this means that the document really
would benefit from significant attention. My issue is that with the
number of questions I am raising I am not able to provide a decent
technical review, and implementers may find this document really hard
work.

I hope that my comments will help improve the document.
         
---

Introduction 

  to efficiently route messages
                                       
"Efficiency" in routing is a concept that may need qualifying. Maybe
you mean select an optimal path. But even that doesn't help much without
some explanation of the paradigm.

---

Introduction

  High Performance Routing:  The very nature of overlay algorithms
      introduces a requirement that peers participating in the P2P
      network route requests on behalf of other peers in the network.
      This introduces a load on those other peers, in the form of
      bandwidth and processing power.  RELOAD has been defined with a
      simple, lightweight forwarding header, thus minimizing the amount
      of effort required by intermediate peers.

Are you saying that that the look-up and forwarding has to be
lightweight? Or are you talking about the routing protocol? Or the
routing algorithm?
                             
---
                             
The concept of "overlay algorithm" is introduced in Section 1 without
really explaining it. Would you add a sentence to explain the purpose
of the algorithm. This will help shape the view of the rest of the
introduction and make it more readable.

A real problem with undertanding in this context is the distinction
between the algorithm that builds selects the nodes and links in the
overlay topology and that which decides the best path for any given
message.

Reading the definition in section 2, the overlay algorithm is only
concerned with building the topology. So there must be a separate
algorithm hiding somewhere in the Topology Plugin that builds the
routing table.

---

I do not believe that this document (and specifically section 9)
contains information to implement chord-reload without reference to
[chord]. That makes [chord] a normative reference.

However, rather than that change, I would prefer this document to be
self-contained, and to include a full implementable description of
chord-reload.

---

Section 3 gives some good input to management although I think the
section is misnamed because a large chunk of the text is about how
the network operates rather than how it is managed.

I think you need to take a look at RFC 5706 for gidance on other
management concepts you should include. I am personally interested in
what OAM mechanisms you propose. (Yes, I do see section 5.5.3, but I
don't believe this is significant OAM in a layer network.)

---

Section 3.3

  Destination Lists:    While in principle it is possible to just
      inject a message into the overlay with a bare Node-ID as the
      destination, RELOAD provides a source routing capability in the
      form of "Destination Lists".  A "Destination List provides a list
      of the nodes through which a message must flow.

s/bare/single/ ?

Spurious quote mark.

Is this an ordered list? I assume so. Please say.
Is this a loose list or a strict list? I assume from the "single node"
option, this is loose. Please say.
What is the minimum content of a list? Presume the destination must be
there. Please say.

---

Section 3.3

I am surprised that the sending-hop node is added to the Via List (in
the figure) by the receiving-hop node. This is not optimal and might be
"entertaining" on multi-access links if such could ever exist.

I would have expected that the sending-hop would add itself prior to
sending the message. This is what other technologies do.

---

Section 3.3


The second figure (for truncated via lists) is broken or confused.

[On the other hand - this might all need to be updated with references
to Section 5.1.3 and "private node id". If so, the issue still remains
that the figure is confused/confusing.]

X1 is added to the Dest List which looks meaningless.
I am also confused that the Destination is faked. Surely that should
never happen.


Are you sure you don't mean (modulo my previous comment about when
Via is added to)...


  A        B        X        Y        Z
  -----------------------------------------

  ---------->
  Dest=Z
  Transact=T
            ---------->
            Via=A
            Dest=Z
            Transact=T
                      ---------->
                      Dest=Z
                      Transact=T
                                ---------->
                                Via=X
                                Dest=Z
                                Transact=T

                                <----------
                                  Dest=Y,X,A
                                  Transact=T
                      <----------
                        Dest=X,A
                        Transact=T
            <----------
              Dest=B,A
              Transact=T
  <----------
    Dest=A
    Transact=T

---

Section 3.5.1

I am having trouble understanding how all nodes in an Overlay Instance
arrange to use the same Overlay Algorithm (which I believe is a
requirement).

Maybe there is a parameter on a Join?
Could this section explain?

---

Section 3.6.1

Should the figure in 1.2 show a component for "Bootstrap and
Configuration"? My issue here is that DNS lives below the Overlay Link
Service Boundary line. Similarly, HTTP is below the line. In some ways
the uses of these services is analagous to the use of ARP and DHCP in
bottstrapping routers and hosts. Can you show how these services fit
in on the diagrams in 1.2?

---

Section 5.1.1

      If the message is a response and there is state for
      the transaction ID, the state is reinserted into the destination
      list before the message is further processed.

There is too much passive voice here for me to work out who carries out
this action.

---

Section 5.2

  An overlay may be configured to use alternative routing
  algorithms, and alternative routing algorithms may be selected on a
  per-message basis.

s/may/MAY/  twice

I think there is something missing in the description. Is the per-
message selection based on a parameter on the message or a local policy?
Does the same routing algorithm need to be used end-to-end for any one
message? (If so, how achieved if not being signaled on the message?)

---

Section 5.2.1

  Parallel searches for the resource are a common solution to improve
  reliability in the face of churn or of subversive peers.

The concept of a "search" is ambiguous here. you have just mentioned
doing an enquiry to the Topology Plugin to determine the appropriate
next hop. Thus, it is not clear whether the search is an algorithm for
searching the routing table, or an algorithm for probing the network.
In the latter case, it is unclear whether the probe is using the message
itself, or using the iterative route query mechanism.

---

Section 5.3.2

  version:  The version of the RELOAD protocol being used.  This is a
      fixed point integer between 0.1 and 25.4.  This document describes
      version 0.1, with a value of 0x01. [[ Note to RFC Editor:  Please
      update this to version 1.0 with value of 0x0a and remove this
      note. ]]

Can you explain why this document has a value in the version field other
than the value that will be in the RFC? Obviously no-one has implemented
and deployed a pre-standard version.

---

Section 5.3.2

  ttl:  An 8 bit field indicating the number of iterations, or hops, a
      message can experience before it is discarded.  The TTL value MUST
      be decremented by one at every hop along the route the message
      traverses.  If the TTL is 0, the message MUST NOT be propagated
      further and MUST be discarded, and a "Error_TTL_Exceeded" error
      should be generated.  The initial value of the TTL SHOULD be 100
      unless defined otherwise by the overlay configuration.

I think there is a little ambiguity about the moment that TTL is
decremented. Could be decrement on tx or rx. Makes a difference to
when a message is discarded, etc.

---

Section 5.3.2.3

      If the
      RESPONSE_COPY flag is set, any node generating a response MUST
      copy the option from the request to the response except that the
      RESPONSE_COPY, FORWARD_CRITICAL and DESTINATION_CRITICAL flags
      must be cleared.

s/must/MUST/

---

Section 5.4.2.1

  In general, nodes which cannot form connections SHOULD report an
  error.  However, implementations MUST provide some mechanism whereby
  nodes can determine that they are potentially the first node and take
  responsibility for the overlay.  This specification does not mandate
  any particular mechanism, but a configuration flag or setting seems
  appropriate.

Isn't it the case that by definition a node that cannot form its first
connection is the first node. That is, it is perfectly possible for a
network to become partitioned and for parts of the network to come up
and operate on their own. It does not seem to me that a configuration
option can instruct a node that it is or is not the first node.

---

Section 5.6.3.1.1

  A node SHOULD retransmit a message if it has not received an ACK
  after an interval of RTO ("Retransmission TimeOut").  The node MUST
  double the time to wait after each retransmission.  In each
  retransmission, the sequence number is incremented.

Please clarify that this is the message originator, not a transit node.

---

Section 9.3.

  If a peer is not responsible for a Resource-ID k, but is directly
  connected to a node with Node-ID k, then it routes the message to
  that node.  Otherwise, it routes the request to the peer in the
  routing table that has the largest Node-ID that is in the interval
  between the peer and k.  If no such node is found, it finds the
  smallest Node-Id that is greater than k and routes the message to
  that node.

Is it not possible that no such node is found, but the network is still
connected.

  m---n---k

Trying to reach k

n < m < k

k is not directly connected to m
n is not in the interval m to k
n is not greater than k

[Ballot comment]
Nothing like getting to your review after there's already 8 lengthy discusses on it.  I'll not be adding anything new (and possibly avoiding the record for total number and length of discusses) - everything I noted somebody else caught.  I'll pop some popcorn and watch p2psip-base vs IESG form the cheap seats.

[Ballot discuss]
This document being the principal specification that defines a new protocol I was expecting to find information concerning operational and manageability considerations. A separate document (draft-ietf-p2psip-diagnostics) defines extensions to the base protocol for diagnostic purposes, and this is fine. However that document is not referred here and there is zero information about how the protocol will be deployed in existing networks, what is the impact on traffic and requirements from hosts, routers, midcom devices (if any), what is the operational model and how is the RELOAD protocol managed in deployments, any hooks for manageability in the software, any defaults for initial configuration, alarm conditions, monitoring of performance.

[Ballot comment]
I have a number of detailed comments/nits below.

==
Bootstrap Node:  A network node used by Joining Peers to help Nlocate
the Admitting Peer.

"Locate," rather than, "Nlocate?"

==

Routing Table:  The set of peers which a node can use to route overlay
messages.  In general, these peers will all be on the connection table
but not vice versa, because some peers will have Attached but not sent
updates.

I had to read this sentence several times to undersand it --maybe just
be more explicit in terms of what could in which table while not being
in the other table.

ICE is used but not defined

Finger table is used before it is described rather than defined, and
the description really only becomes meaningful with knowledge  of
the CHORD paper.

Skiplist could do with a reference other than requiring the reader
to Google for the definition.

[Ballot discuss]
I have needed to read draft-ietf-p2psip-base at least three times and
talked with one of the RAI ADs and a couple of the authors before
being is a position to be moderately confident with the intent
of this document and the operation of the protocols.

I think that the intent is correct and the IETF needs a protocol
that does application layer routing. However I am not yet convinced
that the design chosen is one that is in the best interests of the
Internet, or that the quality of the document is adequate.

The RELOAD protocol is a monolithic re-creation of all seven layers of
the Internet written using application layer terminology and
techniques. It is thus difficult for those familiar with the
classic method of describing such protocols to be confident
that the text provided is complete, consistent and correct,
particularly in the operational corner and pathological cases.

RELOAD is a what is known in the lower layers as a layer network.
It is regrettable that it does not describe the reason to
recursively reuse each of the "classic" Internet protocols
without explaining why each was unsuitable. This is doubly so
because it is possible that where a "classic" protocol
was unsuitable for RELOAD, the corresponding RELOAD component
may have been a valuable addition in the "classic" network
protocol set. It is somewhat ironic that a protocol designed
using applications techniques does not seem to have been
designed to be recursive since the sub-IP, IP and Routing
layers are commonly used recursively.

It is also regrettable that the document is a monolith rather
than using the large set of small documents approach that
has served us so well in the past in the lower layers. I am
concerned that in the long terms this will cause problems with
maintaining and extending the protocol.

To take routing in particular, this scatted over the document
such that the RTG-dir reviewer and myself were concerned that
much of the protocol description was missing. I am concerned
that structure will make it difficult for implementers to understand
all the corner case conditions during coding and test, and
harder for the  operator community to specify and manage their
networks.

I am concerned that the document is really not understandable
without first understanding the CHORD paper, and further
concerned that parts of the CHORD paper are implicitly
normative text in the specification. The technique of
explaining RELOAD-CHORD as a delta on the CHORD paper makes
this particularly problematic. In addition the IETF is not
able to make this essential paper directly available to
readers, nor to issue and manage errata on it.

I am concerned that the only OAM is PING when we have
known for years that to manage a router network you
need at least traceroute and current interest is in
a significantly increased OAM tool set.

If the proposal were to publish RELOAD as experimental I
would leave the draft to it's fate. However it is a Standards
Track Document which means that it has to be sufficiently
free standing and with sufficiently normative text that an
engineer can implement an interworkable version of the
protocol without additional information. Furthermore I
am uncomfortable as to whether the document provides sufficient
detail that two non-interworking implementations can resolve
which is the correct implementation from this specification
alone.

I would prefer that the document be split into a number
of smaller documents: architecture, link connection,
routing, transport, OAM etc in the way that is the
tradition of lower layers. I suspect that this is not
a direction that the authors would wish to take.

I realize that the above is not crafted as an actionable Discuss.
I propose to discuss this on the call with the IESG, and
if no actionable discusses result, or if it is clear that
I am alone in this view, I will move the text above to a
comment and consider abstaining.

[Ballot comment]
1. Regarding communication security, Section 1.3 states:

  Message Level:    Each RELOAD message must be signed.
  Object Level:    Stored objects must be signed by the creating peer.

Did you mean "MUST" instead of "must"?

2. In Section 3.1.1, please provide references for TLS-PSK and TLS-SRP.

3. In Section 3.2.1, please provide a reference for TURN.

4. In Section 3.2.1, forward references would help for Attach (Section
5.1.1), Ping (5.5.3), Destination List (5.3.2.2), etc.

5. Section 3.2.2 mentions "the topology plugin required to act as a
peer in the overlay"; does this assume a plugin architecture for Node
implementations? Perhaps not, because in Section 5.4 the spec talks
about a "Topology Plugin" in a more generic sense. It might be good to
clarify.

6. The description of symmetric recursive routing in Section 3.3 makes
me wonder whether messages themselves are stored at the nodes in the Via
list; if so, does that introduce possible concerns related to privacy,
security, and auditing?

7. Please expand "ICE" on first use (Section 1) and in Section 3.4.

8. Section 3.6.1 states that "the node does a DNS SRV lookup on the
overlay name to get the address of a configuration server"; a forward
reference to Section 10.2 would be appropriate here. Also, a reference
to RFC 2782 seems in order here.

9. Section 3.6.2 states that "the enrollment server's ability to
restrict attackers' access to certificates in the overlay is one of
the cornerstones of RELOAD's security"; by "access" seems to be meant
"privilege to be granted its own certificate", not "capacity to know the
certificates of other nodes".

10. Section 4.1.1 states that "only a user with a certificate for
'alice@example.org' could write to that location in the overlay". At
least a forward reference to Section 10.3 would help, which is the only
place where the user name is a define as an rfc822Name (at least in the
certificate). Furthermore, it would help to more clearly specify how
a user name prepared and compared for authorization purposes.

11. In Section 5.1, what exactly does it mean for a peer to "pass a
message up to the upper layers"?

12. Is there a reason why the end-to-end reliability mechanism in
Section 5.2.1 doesn't recommend exponential backoff on retries?

13. Section 5.3.2 states that "transaction IDs ... MUST be randomly
generated"; perhaps a reference to RFC 4086 is in order?

14. In Section 5.3.3.1, it would be good to state whether the
"error_info" text is intended to be presented to users (if so, we might
need language tagging).

15. In Section 5.3.4, what exactly is "the identity used to form the
signature"? It appears to be a Node-ID (or a hash thereof), but it would
be good to make that clear in the definition (e.g., could it also be a
Resource-ID)?

16. In Section 5.5.1.1, are "srflx", "prflx", and "relay" as defined for
Candidate Types in ICE? The "type" is said to "correspond to the
cand-type production" but it might help to point a bit more directly to
RFC 5245.

17. Section 6.4.1.3 mentions previous versions of RELOAD. Given that no
references are provided, is that mention helpful?

18. The  element is of type xsd:boolean; please
note that this datatype has two lexical representations, "1" or "true"
for the concept true and "0" or "false" for the concept false. You might
want to point this out to implementers. The same applies to the other
elements with a datatype of xsd:boolean (no-ice, clients-permitted,
etc.).

19. Section 10.1 does not clearly specify which elements and attributes
are required and which are optional. Is it assumed that the reader needs
to refer to the schema for this information?

20. In Section 12.3, it might be worthwhile to mention the possibility
of attacks against the central enrollment authority.

21. In Section 13.6, it's still not clear what it means for an XML
format to be binary-encoded. I think this needs to be more clearly
specified, then the registration can reference the appropriate section
of the spec.

[Ballot discuss]
I'd like to talk about several points that I haven't seen mentioned in
other reviews.

1. Section 1.3 appears to couple issuance of certificates and assignment
of Node-IDs (in most cases):

  RELOAD's security model is based on each node having one or more
  public key certificates.  In general, these certificates will be
  assigned by a central server which also assigns Node-IDs, although
  self-signed certificates can be used in closed networks.

What is the reason for this coupling? Does it have security
implications? At the least, a forward reference to later sections
(e.g., 3.1) might help.

2. Does the use of list compression (Section 5.1.2) and private IDs
(Section 5.1.3) prevent an intermediate node from routing return messages
if its neighbor goes offline? In your example, if E has a destination
list of (D, I) but D goes offline, then E won't be able to unpack the
private ID "I" to recover the via list "(A, B, C)".

3. In Section 10.1, the format of the 'expiration' attribute is not
fully specified (e.g., are timezone offsets allowed or must the datetime
be UTC?).

4. Section 10.1 states that "The configuration file is a binary file
and cannot be changed - including whitespace changes - or the signature
will break." The XML file doesn't look very binary to me! But if you
require special formatting then please specify it, for example by saying
that "the configuration file MUST NOT include any whitespace as
separators between XML elements" or somesuch.

5. In Section 10.3, placing the username and password in the clear as
URL parameters seems a bit dodgy even if SSL/TLS is used, since URLs can
be copied or can otherwise leak out.

[Ballot comment]
Page 38 - Section 5.2.1 - might be worth calling out that the sending node will be doing both e2e and hopbyhop retransmissions

Page 48 - Section 5.3.3 - should note 0x8000-0xfffe are reserved

Page 82 - Section 6 - Can you find a different word than "unpartitioning" (or define it)? - it only occurs once in the document.

Page 107 - the formula at the end of 9.5 has unbalanced parentheses

Page 112 - In the implementer note in 9.7.4.3, can you point to references to get the implementer started?

[Ballot discuss]
(updated to capture config-chord and to make the comments easier to read.)

The document does not appear to register the namespaces urn:ietf:params:xml:ns:p2p:config-base and urn:ietf:params:xml:ns:p2p:config-chord?

The definition of the fragment field in 5.3.2 (page 43) should be updated
to reflect the design choices that resulted in the high bit always being set
(as called out at the end of section 5.7). The definition here implies that
the high-bit might not be 1 in a valid message.

I'm not finding specific normative text that describes how an implementation is
handles a message that has an incorrect version number. The first part of 5.1
talks about "can process" and an "appropriate error", but leaves a lot of room
for interpretation on what those mean. Can this be made more explicit?

Section 3.2.1 has a 2119 MUST, but this section is intentionally non-normative.

[Ballot comment]
Page 38 - Section 5.2.1 - might be worth calling out that the sending node
will be doing both e2e and hopbyhop retrasmissions
Page 48 - Section 5.3.3 - should note 0x8000-0xfffe are reserved
Page 82 - Section 6 - Can you find a different word than "unpartitioning" (or define it)? - it only occurs once in the document.
Page 107 - the formula at the end of 9.5 has unbalanced parentheses
Page 112 - In the implementer note in 9.7.4.3, can you point to references to get the implementer started?

[Ballot discuss]
The document does not appear to register the namespace urn:ietf:params:xml:ns:p2p:config-base?

The definition of the fragment field in 5.3.2 (page 43) should be updated
to reflect the design choices that resulted in the high bit always being set
(as called out at the end of section 5.7). The definition here implies that
the high-bit might not be 1 in a valid message.

I'm not finding specific normative text that describes how an implementation is
handles a message that has an incorrect version number. The first part of 5.1
talks about "can process" and an "appropriate error", but leaves a lot of room
for interpretation on what those mean. Can this be made more explicit?

Section 3.2.1 has a 2119 MUST, but this section is intentionally non-normative.

[Ballot comment]
- It may be a good idea near the beginning of section 1 to be clear as
  to whether RELOAD is intended to setup P2P overlays per-application using
  RELOAD, or to setup a single Internet-wide RELOAD overlay that many
  applications would commonly utilize.  Some of the phrasing later in
  the section can be interpretted either way, e.g. "The RELOAD network"
  in 1.1 and "RELOAD is fundamentally an overlay network" implies that there
  is only one and that it can be what the name RELOAD refers to rather than
  just the protocol.  But, of course, this is inconsistent with what other
  parts of the same sections imply.  I could see some people being confused.

  The terminology actually clarifies it by defining "overlay instance", but
  that isn't until section 2.  It's worth clarifying early on since there
  have historically been P2P protocols that were single-network in their
  operation, and so this vision exists in some heads.

- In the figure on page 13, "TLS" and "DTLS" might more appropriately be
  "TLS/TCP" and "DTLS/UDP" in order to include the actual transport
  layer protocols themselves.

- In section 3.1, there may be some confusion between certificates being
  given to "nodes" versus "users".  The text is clear that there can be
  multiple nodes serving a single user.  It might need to explicitly
  state whether or not a single node can serve multiple users.  For
  potential integration into systems like ISP caches this distinction
  may be important to clarify.

- Section 3.3 mentions NAT traversal as a routing requirement, but it
  was previously described in section 1 as being a part of the
  forwarding sub-layer and not the routing sub-layer.  I think that the
  "routing" in 3.3 encompasses both sub-layers (and maybe more) the
  way that it's being described there.

[Ballot comment]
- It may be a good idea near the beginning of section 1 to be clear as to
  whether RELOAD is intended to setup P2P overlays per-application using
  RELOAD, or to setup a single Internet-wide RELOAD overlay that many
  applications would commonly utilize.  Some of the phrasing later in
  the section can be interpretted either way, e.g. "The RELOAD network"
  in 1.1 and "RELOAD is fundamentally an overlay network" implies that there
  is only one and that it can be what the name RELOAD refers to rather than
  just the protocol.  But, of course, this is inconsistent with what other
  parts of the same sections imply.  I could see some people being confused.

  The terminology actually clarifies it by defining "overlay instance", but
  that isn't until section 2.  It's worth clarifying early on since there
  have historically been P2P protocols that were single-network in their
  operation, and so this vision exists in some heads.

- In the figure on page 13, "TLS" and "DTLS" might more appropriately be
  "TLS/TCP" and "DTLS/UDP" in order to include the actual transport
  layer protocols themselves.

- In section 3.1, there may be some confusion between certificates being
  given to "nodes" versus "users".  The text is clear that there can be
  multiple nodes serving a single user.  It might need to explicitly
  state whether or not a single node can serve multiple users.  For
  potential integration into systems like ISP caches this distinction
  may be important to clarify.

- Section 3.3 mentions NAT traversal as a routing requirement, but it
  was previously described in section 1 as being a part of the
  forwarding sub-layer and not the routing sub-layer.  I think that the
  "routing" in 3.3 encompasses both sub-layers (and maybe more) the
  way that it's being described there.

[Ballot discuss]
Multi-part DISCUSS, which I think requires a document update (and possibly more
discussion, though the email thread between Michael Scharf and Bruce is a great
start):

(1) Section 5.6.3.1 has a handwave about TFRC and TFRC-SP, however those both
require description of how both sender and receiver-side information can be used
to compute loss intervals and measure losses, which isn't here, and may not
even be necessary here.  The section is "retransmission and flow control" but
those are both distinct (though coupled) with congestion control, and TFRC
answers neither.  I don't think the mention of TFRC is even proper and not related
to the rest of the section since it's more for applications that are streaming out
data at some controlled rate, rather than sending messages and waiting for
acknowledgements on them or retransmission events.  What's here doesn't seem
to relate.


(2) As noted by Michael Scharf, the RTO computation text in section 5.6.3.1.1
has a confused (or confusing) citation of RFC 6298 and may lead to instability in
presence of RTT variations.


(3)  During discussion of the tsv-dir review from Michael Scharf, it became evident
that some issues are confusing in the split between the functionality for end-to-end
message transport across the overlay versus similar functions that exist
hop-by-hop in the overlay (e.g. by using TCP).  Some cases where this was apparent:
- in the section 1.2.5 mention of "reliability, congestion control, flow control, etc"
- in the timer discussion around section 5.2.1
- in the discussion of head-of-line blocking around section 5.5.1.6
- in section 5.6.3, throughout the section

It would be good for clarity to have some text in the architecture section to describe
the envisioned division of labor between the overlay protocol and the underlying
(layer-4) transports that are used in the "link" layer and how those relate to the
message transport sub-layer of RELOAD, especially since those transports offer
different services to the application.  Otherwise, problems with nested control
loops that exist between layer-4 protocols and various layer-2 technologies can
similarly arise in RELOAD use.

[Ballot comment]
3.1 - The concept of "user" appears in this section along with "username", but it never really gets defined, or for that matter is understandable at all, until 6.3. Some introduction to "user" might be nice somewhere at or before 3.1.

5.1.1 - If a wildcard Node_ID is used, does the does the message get sent to the Message Transport for forwarding? Not spelled out in this section.

5.3.3.1 - Editing error: Error_Data_Too_Old is followed by Error_Data_Too_Old

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

5.5 - Not clear to me why this document settles on ICE (or anything lower layer). Seems like it could have been abstracted out and left to a different layer. I'm kind of disappointed that all of section 5.5 (and maybe sections 5.6 and 8) is not a separate document.

[Ballot comment]
[Still editing these comments. You may answer them, but they may change.]

3.1 - The concept of "user" appears in this section along with "username", but it never really gets defined, or for that matter is understandable at all, until 6.3. Some introduction to "user" might be nice somewhere at or before 3.1.

5.1.1 - If a wildcard Node_ID is used, does the does the message get sent to the Message Transport for forwarding? Not spelled out in this section.

5.3.3.1 - Editing error: Error_Data_Too_Old is followed by Error_Data_Too_Old

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

5.5 - Not clear to me why this document settles on ICE (or anything lower layer). Seems like it could have been abstracted out and left to a different layer. I'm kind of disappointed that all of section 5.5 (and maybe sections 5.6 and 8) is not a separate document.

[Ballot discuss]
So I have a humongous set of discusses and comments on this
humongous document. (Probably some of the comments at
least are because this is the first time I've read any of this.)
But, don't get the wrong idea - I quite like this and hope it becomes
an RFC as soon as its ready. Right now though, its not quite ready.

(1) section 3.1: Is collision resistance needed for the case where the
Node-ID is a digest of the node's public key?  How is node key
rollover done?  Do I loose all stored data?  I think you need to
make all those clear.

(2) section 5.1: Does "correctly formatted" include checking signatures
etc? I think you probably mean that it does include signature checking,
but you need to say that.

(3) section 5.1.1: I assume the list entries here are meant to be
mutually exclusive and I'm not meant to do all that apply? Or am I
meant to do the first case that applies. Saying that would be good.
Does the last bullet need to say "not equal to this node and not the
wildcard ID"?

(4) cleared

(5) section 5.3.4: You say that signatures MUST be checked but don't
say how to handle bad signatures. I assume you drop the message?
(Since there are no bad-signature error codes defined.)

(6) section 5.4.2.1: This doesn't say that the JoinAns MUST come from
the peer to which the Join was sent. I think that's needed.

(7) section 5.4.2.1: What prevents/detects replay of JoinReq messages?
If replay worked, then I could cause lots of havoc since the
responding peer will do a bunch of Stores and Updates. 

(8) section 5.4.2.2: What prevents/detects replay of LeaveReq
messages? Seems like an obvious DoS if possible.

(9) section 6: is there supposed to be a relationship between the
notAfter value from certificates and the sum of storage_time and
lifetime? I think you need to say something here as otherwise data
could be stored beyond the time at which its signatures are
verifiable.  I don't mind if you say that cert.notAfter is the max or
if you say to ignore cert.notAfter but if you say nothing different
implementers are likely to do different things.

(10) section 6.4.2.2: I think you need to say whether or not the
signatures in the StoredData MUST be checked here.  I assume you do
want them checked but you don't say.

(11) section 6.4.2.2:  If the signer's cert has expired, is a
signature on a stored value still considered valid or not?  One issue
is that if any revocation/status checking is supported then there may
not be any such information available for expired certs. Another issue
is that if you do consider signatures only verifiable with non-expired
certs, then a lot can go wrong when a cert expires and its hard to fix
that up. I don't have a good solution to offer, but maybe you have an
answer?

(12) section 7: I don't see how to send a reference to a certificate -
5.3.4 doesn't seem to allow for that now - wouldn't you need a new
CertificateType for that?

(13) section 10.1: I don't get  - is that mode really
well-specified? Seems like you're publishing a shared-secret which
isn't really secret then is it? Or did I miss something? Maybe you
want to say that configurations that use this MUST NOT be publically
available and MUST be locally installed in a trusted way or something
like that?

(14) section 10.1: You don't say here that the signature(s) MUST
verify for the configuration to be used. Neither do you say that the
signers MUST chain up to the one of the root-cert values included in
the configuration.  I think you could justify not requiring that, but
then you should say so, so that coder's don't do the wrong thing.

(15) section 10.3: Putting the password (or even username) in the
query string is not good practice - those can get logged by servers
accidentally far too easily. Why don't you define a HTML form that you
then POST?

(16) section 10.3: might need to warn against dodgy username values,
e.g.  containing a null character or whatever. I think you need some
more rules there to end up with a safe rfc822name in the cert. (Or
else have an argument that that's not a problem for RELOAD - it has
been a problem elsewhere.) Also, does the enrollment server choose the
domain component of the rfc822 name or may that be supplied by the
client?

(17) section 10.3: What character set is allowed for passwords? What
if something is URL escaped - what's going to match?  I'm sure you can
copy from somewhere else, not quite sure what's best though. 

(18) section 10.3: You say the signer for this exchange MUST be one of
the root-certs from the configuration. I think that that ought say
that it MUST be a CA and it MUST chain up to one of the root-certs.
Why force the root to be online like that?  Or, you could add a new
configuration setting for a user-signing-ca-cert and then it'd be ok
to say that one of those MUST be used for enrollment.

= You could probably say that if this is not a new configuration and
has a root-cert that is common with a previous configuration then the
outet signature MUST verify and MUST chain up to the previous
root-cert.

= I think you can say that the kind-signatures MUST verify and MUST
chain up to a root-cert from the current configuration.

= I think you can say that implementations SHOULD provide a way to
allow completely new configurations, or configuration updates with
only-new root-certs to be accepted but that that's out of scope.

(19) section 13.15: is reg-name sufficiently clear for the overlay
name?  For example, that allows percent encoding - are those variant
names all the same overlay? I guess so, but it'd be good to confirm
and maybe say that in the document.

[Ballot discuss]
The Gen-ART Review by Mary Barnes on 9-August-2011 points out
  significant inconsistencies in the document.  Please resolve these
  inconsistencies.  Please consider the other comments as well; Mary
  offers very helpful suggestions.  The review can be found at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg06582.html.

[Ballot comment]
==
Bootstrap Node:  A network node used by Joining Peers to help Nlocate
the Admitting Peer.

"Locate," rather than, "Nlocate?"

==

Routing Table:  The set of peers which a node can use to route overlay
messages.  In general, these peers will all be on the connection table
but not vice versa, because some peers will have Attached but not sent
updates.

I had to read this sentence several times to undersand it --maybe just
be more explicit in terms of what could in which table while not being
in the other table.

[Ballot discuss]
I have read the document a couple of times and I concur with the
review from the Routing Directorate:

=====
5.4.2.4 appears to be the only real explanation of the routing mechanism:

1. Develop a need to send some message to a given destination.
2. Choose a random peer and ask how they would get there.
3. If that peer doesn't know, they repeat the process.

The problem is, of course, there's no way to "end" the query (it could
loop forever in the network?), and there's no way to know if the path is
anything like optimal across the overlay. I would think something more
robust is required to provide routing across the network.

=====
Is there some other description of the routing algorithm we are missing in
the document  - if so please make it more obvious to the reader. If not
then the authors need to confirm that the text provided has de-facto been
sufficient to implement the standard from the text of this document
alone, or to incorporate the required additional text.

[Ballot comment]
overall:

- I've got to say that this reads a lot like an experimental
specification. Its so complex and has so many moving parts and ways to
plug stuff in, I wonder if its really at the right stage for the
standards track. While I'm willing to believe the WG/AD that it is
(almost;-) ready, I'm still worried a bit that a whole bunch of things could
turn up when its deployed.

- The IPR declaration appears to be for something that has (as far as
I can see) nothing whatsoever to do with the protocol. Who knows, but
the filing seems to be about MIMO, which is a fairly low in the stack
thing to be related to an overlay on top of (D)TLS. Wouldn't it be
nice if that hadn't happened?

- This reminds me of DTNs [rfc4838,rfc5050] but witout the disruption
tolerance. Interestingly, if the timer defaults were made to be part
of the overlay then it could actually be used for a DTN.  I can also
imagine that other overlays might benefit from being able to modify
the timer defaults either up or down - so would it be worthwhile
allowing the overlay config to override or specify those default
values?

- There's a lot of lowercase occurrences of "must." It'd be great if
you could clean that up, e.g. saying if they're meant as RFC 2119
terms or not, e.g. 3.3's 1st few uses of "must" seem like they are
2119 terms, but not all others are, e.g. the last one in 3.2.

- A number of the detailed comments below were written as I was
reading the document, and relate to stuff that became clear as
I read further. If the comments says "but what about ?"
and  is explained later on, that means that I didn't get
on first reading to that point. You might want to consider
adding some text or a forward reference in some of those cases.
I've marked those with (*) in case you want to do that.

section 1:

- It'd be good to restate the peer/client distinction here (from e.g.
the charter) at the very top, e.g. moving the 2nd last para of 1.1
earlier

- Can "high performance" be quantified? If not, then is it really a
"feature"?

- Maybe add a reference to [Chord] in the intro?

section 1.1:

- "connected graph" assumes always-on? needs to be clear, maybe not a
great term

(*) I was wondering what the lifecycle of a Node-ID might be. It became
clear, but only *much* later.

- "also a storage network" - can I store my 24GB of photos using this?
if not (as I expect) then that'd be better stated here.

section 1.2.2:

- maybe clarify that you don't mean cryptographic keys

- add a reference for KBR

section 2:

(*) what's the lifecycle of a Kind-ID? are these also fixed length?

(*) what's the "fixed length" of a Node-ID?

(*) can a single peer/client instance be part of >1 overlay instance at
once? I guess that's just an implementation issue for the peer/client,
but wondered if there's anything that'd prevent that or make it hard.

- typo: "Nlocate" ?

- "Joining Peer" and "Admitting Peer" are those only for peers or
clients too? If the latter, then Node would be right I guess? Section
3 seems to imply that node would be more correct here.

- Connection Table definition refers to Attach handshakes and Updates
but those haven't been introduced yet. Might be better to use natural
language rather than those terms at this point if there's an easy way
to do that.

- Routing Table - the sentence "In general,..." is confusing. You also
use "Attached" but haven't yet said what that means. Maybe just say
that the routing table is a subset of the connection table if that's
the case.

(*) Destination List - isn't that a source route? If not, what's
different? If so, why not say so? Does it include the IDs through
which the message has already been routed or not? Later, (in 5.1.1) I
find out that the earlier IDs are dropped, saying that here would be
good. And also say that its not just Node-IDs, but also Resource-IDs,
that wasn't clear 1st time.

- The last paragraph here seems oddly detailed compared to the others
- would it be better elsewhere? As-is, there's not enough in this
paragraph for the reader to understand this having read to this point
so I think moving would be better. (Not sure where yet.)

section 3.1:

(*) how is the Node-ID included in the cert?

(*) what is "the user name found in the certificate"? that wasn't a
defined term - shouldn't it be? Where is it in the cert? is there just
one user name per cert/user/device?

- 3.1.1 is very short and needs references and maybe more.

section 3.2:

(*) this is the first time that the peer/client distinction and storage
have been mentioned together.  Are clients allowed to/required to be
able to store stuff?

- If peers "typically" have "storage responsibilities" does that mean
some peers may never store stuff?  How can the overlay tell if that's
the case and not try store stuff at that peer?

- 2nd para here is mostly a repeat. Better to not do that.

section 3.2.1:

- 2nd para/bullet needs some work. "The client can initiate..."
sentence has a few unclear instances of "it" and the following
sentence has one too ("to reach it").

- "learnable via other mechanisms" are those specifed?  if not, then
how will it work interoperably?

(*) the text about Node-IDs in certs and Attach/Ping can't be
understood at this stage in reading.

section 3.2.2:

- the list of things a client must (not MUST?) do could really do with
cross references to the relevant sections where a coder can find the
stuff they need.

(*) this says all client (and I guess peer) implementations are
overlay-specific, is that right?  if so, that seems to break the
architecture or does it?

section 3.3:

- what is "significant state"?

- Saying "In all cases, the response...needs to (be) delivered..."
seems to be a very hard requirement. Does this protocol really meet
that requirement?

- Saying "...and not to some other node." is odd. I'm not clear what
you really mean.

- I guess inverting the via list can fail if the topology has changed.
Is this handled? What happens?

- This is the 1st occurrence of the term "transaction id." That should
be in the terminolgy section really.  Who creates these and with what
scope (e.g.  do they need to be globally unique?)

- The figures in 3.3 could do with captions so they can be referenced.
(Same is true generally.)

- The text says that using a transaction id means not having to change
the message, but seems to involve changing the response message. If
so, that should be stated. If not, then briefly saying how that works
would be good.

section 3.4:

- This says that 3.2.1 describes a case of a direct connection to an
arbitrary IP address, but I didn't see mention of that there.

- "need to periodically verify" connections - I assume that's defined
later on in detailmentions

section 3.5:

- typo: using CHORD or Chord consistently would be better

section 3.5.2:

(*) I assume the cache TTL is specified later

- Does caching the set of nodes "it has connected to with public IP
addresses" mean a node has to know all the bogons and not cache those
or is the mention of "public" here just a reference to the bootstrap
phase?  (the grammar's not great there either, "nodes to which it has
connected" would be better:-)

- How is the first-ever-node case handled if the network is
temporarily entirely disconnected? Is there a need for a MUST NOT for
implementers that are developing "ordinary" nodes or something?
Without that, how can the node tell if its really the first one or
not?

section 3.6:

- the term "user" wasn't defined - I think it'd be worth doing that to
distinguish it from client/node.

section 3.6.1:

- What trust anchor is to be used for this HTTPS connection? (And add
a reference to 2818 I guess.)

- Does the HTTPS connection here need a reference to 6125? If not,
then is the overlay name supposed to be in the server cert? If not,
then how do I know I've been sent to the right place?

- section 3.6.2:

- If the config document says who's the trust anchor for the overlay
then it probably MUST be gotten securely. But that's not stated. If
this is done in the open, then being clear about the leap-of-faith
step would be good. I mean saying what's important there, exactly when
it happens, what might go wrong etc. That may be later but putting it
here (or a forward reference) seems like its needed.

section 4.1

(*) Signatures imply some c14n rule, esp if supporting
array/dictionary.  Is this covered?

section 4.2:

- the list could do with forward references to places where these
items are detailed.

- Didn't it say earlier that Resource-ID=hash(name) was just an
example?

- "...after a network partition." Do you mean "...after a network
partition is healed"? In any case that paragraph confuses me. This is
also the first mention of time sync, so a bit more introductory text
seems needed.

section 5.1:

- This is the 1st mention of the wildcard Node-ID, that should go in
section 2 as well and needs definition. I guess its like an anycast
and not a multicast, unless the overlay does some kind of message
replication.

section 5.1.1:

- This is the 1st time that I figured out that a Resource-ID could be
on a destination list. That should be stated in section 2 which
doesn't make that clear.

- The 2nd bullet says forward the thing but makes no mention of the
Via field. Isn't that needed? (5.1.2 does mention it.)

section 5.1.2:

- It seems odd to have the middle case in presentation order say "if
neither of the other ... apply" since I've not yet read 5.1.3. Maybe
re-order the sections?

- Should that say "neither of the other *two* cases"?  5.1 only has 3
bullets and "neither...three..." would be odd. Or am I missing even
more than usual;-)

- "likely to be responsible" is very wooly, as is "consults" the
routing table.

- Why is it a SHOULD for the case where the 1st entry is on the
connection table? Didn't you define the routing table just to make
this distinction?  If the SHOULD is right, then what's the exception?

- "This may be arranged in one of two ways..." and then you have two
MAY statements. There's a MUST missing here.

- The transaction ID example seems to have node C (or A or B) create
the transaction ID and not node D. That should be stated. (I assume
its really the initiator who creates it.)

- Saying "It MAY either be a compressed..." is a bit confusing. I
guess those aren't the only options? (I could encrypt the list to make
a private ID if I wanted, right?)

- What is "FORWARD_CRITICAL"? This seems like an odd place to
introduce the 3 second timer.

section 5.2:

- If alternative routing can be selected on a per-message basis and a
node doesn't support that routing scheme, then what does it do?  Drop
the message or use the MTI scheme? Or is this embedded in the overlay
name/ID?

section 5.3.2:

- Is the overlay name that is hashed into the overlay 32 bit value
case (in)sensitive or just treated as octets? If SRV records are used
bootstrapping for this I guess something may need to be said about
this.

- "MUST be randomly generated" - it'd be good to give guidance here
about PRNGs, e.g. maybe cite 4086?

- You don't say where to put a new entry in the via_list.  I assume
its at the end furthest from the start of the message.

section 5.3.2.2

- compressed_id was earlier called private ID - why change?

section 5.3.2.3

- the struct has flags before length but the descriptions are length
and then flags. But the length desription says "...rest of the
structure" which could be interpreted to include the flags field. I
guess it oughtn't and just moving the length description should fix
this. Also saying the option value is "length" bytes would be good and
giving an exanple of how to handle length==0 would help too.

section 5.3.3:

- The criticial field in extensions has proved to be slightly
problematic in X.509 over the years. The debate arises now and then as
to what "understand the message" means, with some saying just knowing
the type means you understand it, others saying you need to be able to
do all processing defined for the extension type and some in between.
It would be good to be more specific here about what "understand the
message" means, for example saying that any relevant MUSTs and SHOULDs
are supported or something like that. I'm happy to remove this discuss
point as soon as I'm told the WG thought about this and its ok as-is,
but wanted to check.

section 5.3.3.1

- error_info is a UTF-8 string unless otherwise stated. Is this
intended for human consumption or not? If so, then how are language
issues to be handled?

- I'm not clear as to whether the error_info for the various
error_code values is expected to be as described here. For example, if
the error is Error_Forbidden, does the description of that imply
something about what goes into error_info or not?

- typo: Error_Data_Too_old is repeated.

section 5.3.4:

- might be no harm to also say that the NodeID in H(NodeID ||
certificate) MUST be in network byte order? Saying "simple raw bytes"
could cause endian-issues there.

- This says that "receiving nodes" MUST verify the signature. Earlier
it said that nodes just need to check formatting (in 5.1). That seems
to be a conflict.  See also discuss point (2).

- I don't get how the first additional check works if the response has
a via - I thought that that meant that the nodes on the path for the
response didn't need state? If so, then how does the verifier here
know who originated the request to which this is a response?

- The 2nd additional check is a bit unclear for me. It says that
response-sender-node-ID MUST be as close or closer to the resource-id
in the *requesting node's* neighbour table. How does a verifier in the
middle of the path get to see the requesting node's neighbour table?

section 5.4.1:

- Has anyone specified a topology plugin other than the MTI one from
here? I'm wondering if the list here is really complete and doable.
(It'd be easy to get this wrong.)

section 5.4.2.1:

- Which error SHOULD nodes sent if they cannot form connections?

section 5.6.3.1:

- Is the "no more aggressive than TFRC" sentence here clear?

section 6.1:

- given that the StoredDataValue can be up to 4GB would it be better
to put the SignerIdentity before that in the signature input? That
might help the verifier go quicker in the case of LARGE data values I
guess.

section 6.2:

- Is 2^32-1 octets really expected to be supported here? Might there
be a case for distinguishing small (say up to N KB) from larger data
values?  (Just checking)

section 6.2.3:

- it'd be no harm to say what you get when a non-existent dictionary
key is used in a query, as you did in 6.2.2 for arrays.

section 6.4.1.1:

- this introduces the "anonymous" and "none" values for
SignatureAndHashAlgorithm on page 88.  That really needs to be
introduced where signing is first discussed and you need to say when
its allowed to be used and for what. (In this part you just say it
cannot be used.)

section 6.4.1.3:

- "(unlike previous versions)" - if there's nothing you can reference
then I'd suggest taking this out - it might have been useful for the
WG but might just confuse the RFC reader.

section 6.4.2.1:

- I don't get the last sentence - how does the requester ask for the
user's cert? And should that say owner's cert? (That may be just due
to how long it's taken me to read this, at multiple sittings;-)

section 8:

- You should probably add a reference for the "private address range"
and think about whether or not the putative new private allocation
counts there too. (It may be that getting this document finished takes
long enough that that process is done.)

section 9.7:

- You RECOMMEND that a peer maintain O(log(N)) things in the neighbour
set. I'm not clear how the peer knows the value of N there?

section 10.1

- This is not right! Why not use a real  in the example?
If the example could be verified that'd help coders.

- You might say is ascii-hex values can be mixed case or not. Be a
shame to fall over because of that and coders might make different
assumptions.

- Why are we not using XMLDSIG for the signatures here?  (Only
kidding:-)

section 10.2

- s/by determines/by determining/

- Isn't RFC6125 a better reference here than 2818?

- Does this practically mean that overlays should be named using DNS
names? If so, saying that early would be good rather than on p124.

- s/such an/such as an/

section 10.3:

- Does the enrollment server web server cert have to have any
relationship with the configuration?  I don't think that's needed, but
am not sure. It'd be good to say either way though.

- Using HTTP errors is fairly coarse grained. In particular don't you
want to have a way to say "everything's fine but you asked for too
many nodeids"? If there's a good HTTP error for that then calling it
out would be good. Just a bare 4xx for username/password errors is
fine though.

section 12:

- Do you need to reference the TLS re-negotiation bug RFC?  Would it
have a bad impact here? (Not sure.)

section 13.5

- I don't get why you have two SIP entries there. It'd be nice to
know.

[Ballot discuss]
So I have a humongous set of discusses and comments on this
humongous document. (Probably some of the comments at
least are because this is the first time I've read any of this.)
But, don't get the wrong idea - I quite like this and hope it becomes
an RFC as soon as its ready. Right now though, its not quite ready.

(1) section 3.1: Is collision resistance needed for the case where the
Node-ID is a digest of the node's public key?  How is node key
rollover done?  Do I loose all stored data?  I think you need to
make all those clear.

(2) section 5.1: Does "correctly formatted" include checking signatures
etc? I think you probably mean that it does include signature checking,
but you need to say that.

(3) section 5.1.1: I assume the list entries here are meant to be
mutually exclusive and I'm not meant to do all that apply? Or am I
meant to do the first case that applies. Saying that would be good.
Does the last bullet need to say "not equal to this node and not the
wildcard ID"?

(4) section 5.2.1: Can the following happen? A sends a Store request
with trans id X, that gets retransmitted up to the re-tx limit, (5
times) with no response received. The first 4 messages get lost. A
then sends an updated request with trans id Y and an updated value to
store, but the trans id Y request arrives at the responsible node just
before the last trans id X request. The result is that the value from
trans id Y is overwritten by the earlier value from trans id X. If so,
what prevents this or what text is needed to tell nodes or usages to
do the right thing? It may be there and I missed it, or maybe the last
sentence of 5.2.1 is meant to address this, but it doesn't really
explain it to me. (To make it worse, the response to trans id X might
arrive back at A before the response to trans id Y.)

(5) section 5.3.4: You say that signatures MUST be checked but don't
say how to handle bad signatures. I assume you drop the message?
(Since there are no bad-signature error codes defined.)

(6) section 5.4.2.1: This doesn't say that the JoinAns MUST come from
the peer to which the Join was sent. I think that's needed.

(7) section 5.4.2.1: What prevents/detects replay of JoinReq messages?
If replay worked, then I could cause lots of havoc since the
responding peer will do a bunch of Stores and Updates. 

(8) section 5.4.2.2: What prevents/detects replay of LeaveReq
messages? Seems like an obvious DoS if possible.

(9) section 6: is there supposed to be a relationship between the
notAfter value from certificates and the sum of storage_time and
lifetime? I think you need to say something here as otherwise data
could be stored beyond the time at which its signatures are
verifiable.  I don't mind if you say that cert.notAfter is the max or
if you say to ignore cert.notAfter but if you say nothing different
implementers are likely to do different things.

(10) section 6.4.2.2: I think you need to say whether or not the
signatures in the StoredData MUST be checked here.  I assume you do
want them checked but you don't say.

(11) section 6.4.2.2:  If the signer's cert has expired, is a
signature on a stored value still considered valid or not?  One issue
is that if any revocation/status checking is supported then there may
not be any such information available for expired certs. Another issue
is that if you do consider signatures only verifiable with non-expired
certs, then a lot can go wrong when a cert expires and its hard to fix
that up. I don't have a good solution to offer, but maybe you have an
answer?

(12) section 7: I don't see how to send a reference to a certificate -
5.3.4 doesn't seem to allow for that now - wouldn't you need a new
CertificateType for that?

(13) section 10.1: I don't get  - is that mode really
well-specified? Seems like you're publishing a shared-secret which
isn't really secret then is it? Or did I miss something? Maybe you
want to say that configurations that use this MUST NOT be publically
available and MUST be locally installed in a trusted way or something
like that?

(14) section 10.1: You don't say here that the signature(s) MUST
verify for the configuration to be used. Neither do you say that the
signers MUST chain up to the one of the root-cert values included in
the configuration.  I think you could justify not requiring that, but
then you should say so, so that coder's don't do the wrong thing.

(15) section 10.3: Putting the password (or even username) in the
query string is not good practice - those can get logged by servers
accidentally far too easily. Why don't you define a HTML form that you
then POST?

(16) section 10.3: might need to warn against dodgy username values,
e.g.  containing a null character or whatever. I think you need some
more rules there to end up with a safe rfc822name in the cert. (Or
else have an argument that that's not a problem for RELOAD - it has
been a problem elsewhere.) Also, does the enrollment server choose the
domain component of the rfc822 name or may that be supplied by the
client?

(17) section 10.3: What character set is allowed for passwords? What
if something is URL escaped - what's going to match?  I'm sure you can
copy from somewhere else, not quite sure what's best though. 

(18) section 10.3: You say the signer for this exchange MUST be one of
the root-certs from the configuration. I think that that ought say
that it MUST be a CA and it MUST chain up to one of the root-certs.
Why force the root to be online like that?  Or, you could add a new
configuration setting for a user-signing-ca-cert and then it'd be ok
to say that one of those MUST be used for enrollment.

= You could probably say that if this is not a new configuration and
has a root-cert that is common with a previous configuration then the
outet signature MUST verify and MUST chain up to the previous
root-cert.

= I think you can say that the kind-signatures MUST verify and MUST
chain up to a root-cert from the current configuration.

= I think you can say that implementations SHOULD provide a way to
allow completely new configurations, or configuration updates with
only-new root-certs to be accepted but that that's out of scope.

(19) section 13.15: is reg-name sufficiently clear for the overlay
name?  For example, that allows percent encoding - are those variant
names all the same overlay? I guess so, but it'd be good to confirm
and maybe say that in the document.

[Ballot discuss]
I would like to talk about the topic of vulnerabilities of RELOAD's source routing capability. As you know, source routing mechanisms have had serious security problems, for instance problems with the IPv6 routing header type 0 lead to its deprecation in RFC 5095.

Section 12.6 of the RELOAD document says:

  Because the storage security system guarantees (within limits) the
  integrity of the stored data, routing security focuses on stopping
  the attacker from performing a DOS attack that misroutes requests in
  the overlay.  There are a few obvious observations to make about
  this.  First, it is easy to ensure that an attacker is at least a
  valid peer in the Overlay Instance.  Second, this is a DOS attack
  only.  Third, if a large percentage of the peers on the Overlay
  Instance are controlled by the attacker, it is probably impossible to
  perfectly secure against this.

And I agree with these statements. However, I would like to see at least some analysis of the vulnerabilities of your source routing mechanism. You should assume that there can be malicious insiders in an instance. After all, you are talking about P2P networks. How serious are attacks from these devices? What kind of amplification factors might be achieved through an attack?

IANA understands that, upon approval, there are sixteen IANA Actions
that must be completed.

First, in the Well-Known URI registry located at:

http://www.iana.org/assignments/well-known-uris/well-known-uris.xml

a new Well-known URI will be registered as follows:

URI Suffix: p2psip-enroll
Change Controller: IETF
Reference: [ RFC-to-be ]
Related information: none

Second, In the port number registry located at:

http://www.iana.org/assignments/port-numbers

port number 6084 will be updated to be for use with both TCP and UDP

Third, IANA will create a new registry that contains the registries that
are required for the RELOAD protocol and architecture. Inside the new
registry will be a series of subregistries. The first of these will be a
new "RELOAD Overlay Algorithm Type" Registry.

Entries in the new "RELOAD Overlay Algorithm Type" Registry are strings.
The registration policy for this registry will be IETF Review as defined
in RFC 5226. The initial contents of the new registry will be:

Algorithm Name Reference
----------------------- ----------------
CHORD-RELOAD [ RFC-to-be ]

Fourth, in the new registry created in task three above, another new
registry will be created called the "RELOAD Access Control Policy" Registry.

Entries in the "RELOAD Access Control Policy" Registry are strings. The
registration policy for this registry will be Standards Action as
defined in RFC 5226. The initial contents of the new registry will be:

Access Policy Reference
----------------------- ----------------
USER-MATCH [ RFC-to-be ]
NODE-MATCH [ RFC-to-be ]
USER-NODE-MATCH [ RFC-to-be ]
NODE-MULTIPLE [ RFC-to-be ]

Fifth, in the new registry created in task three above, another new
registry will be created called the "RELOAD Application-ID" Registry.

Entries in this registry are 16-bit integers denoting application kinds.
The registration policy for this registry will be Standards Action as
defined in RFC 5226 for the values in the range 0x0001 to 0x7fff. The
registration policy will be Expert Review as defined in RFC 5226 for
values in the range 0x8000 to 0xf000. Values in the range 0xf001 to
0xfffe are reserved for private use.

The initial contents of this registry are:

Application Application-ID Reference
------------ -------------------- ---------------
INVALID 0 [ RFC-to-be ]
SIP 5060 [ Reserved for use by SIP Usage ]
SIP 5061 [ Reserved for use by SIP Usage ]
Reserved 0xffff [ RFC-to-be ]

Sixth, in the new registry created in task three above, another new
registry will be created called the "RELOAD Data Kind-ID" Registry.

Entries in this registry are 32-bit integers. The registration policy
will be as follows for this registry:

Values in the range 0x00000001 to 0x7fffffff require Standards Action as
defined in RFC 5226.
Values in the range 0x8000000 to 0xf0000000 require Expert Review as
defined in RFC 5226.
Values in the range 0xf0000001 to 0xfffffffe are reserved for private
use via the kind description mechanism described in Section 10 of
[RFC-to-be ].

The initial contents of this registry are:

Kind Kind-ID Reference
------------------- ---------------- ----------------
INVALID 0 [ RFC-to-be ]
TURN_SERVICE 2 [ RFC-to-be ]
CERTIFICATE_BY_NODE 3 [ RFC-to-be ]
CERTIFICATE_BY_USER 16 [ RFC-to-be ]
Reserved 0x7fffffff [ RFC-to-be ]
Reserved 0xfffffffe [ RFC-to-be ]

Seventh, in the new registry created in task three above, another new
registry will be created called the "RELOAD Data Model" Registry.

Entries in this registry are strings. The registration policy for this
new registry will be Standards Action as defined in RFC 5226.

The initial contents of this registry are:

Data Model Reference
-------------------- ------------------
INVALID [ RFC-to-be ]
SINGLE [ RFC-to-be ]
ARRAY [ RFC-to-be ]
DICTIONARY [ RFC-to-be ]
RESERVED [ RFC-to-be ]

Eigth, in the new registry created in task three above, another new
registry will be created called the "RELOAD Message Code" Registry.

Entries in this registry are 16-bit integers. The registration policy
for this new registry will be Standards Action as defined in RFC 5226.

The initial contents of this registry are:

Message Code Name Code Value Reference
------------------------------- ------------------ -------------------
invalid 0 [ RFC-to-be ]
probe_req 1 [ RFC-to-be ]
probe_ans 2 [ RFC-to-be ]
attach_req 3 [ RFC-to-be ]
attach_ans 4 [ RFC-to-be ]
unused 5 [ RFC-to-be ]
unused 6 [ RFC-to-be ]
store_req 7 [ RFC-to-be ]
store_ans 8 [ RFC-to-be ]
fetch_req 9 [ RFC-to-be ]
fetch_ans 10 [ RFC-to-be ]
unused (was remove_req) 11 [ RFC-to-be ]
unused (was remove_ans) 12 [ RFC-to-be ]
find_req 13 [ RFC-to-be ]
find_ans 14 [ RFC-to-be ]
join_req 15 [ RFC-to-be ]
join_ans 16 [ RFC-to-be ]
leave_req 17 [ RFC-to-be ]
leave_ans 18 [ RFC-to-be ]
update_req 19 [ RFC-to-be ]
update_ans 20 [ RFC-to-be ]
route_query_req 21 [ RFC-to-be ]
route_query_ans 22 [ RFC-to-be ]
ping_req 23 [ RFC-to-be ]
ping_ans 24 [ RFC-to-be ]
stat_req 25 [ RFC-to-be ]
stat_ans 26 [ RFC-to-be ]
unused (was attachlite_req) 27 [ RFC-to-be ]
unused (was attachlite_ans) 28 [ RFC-to-be ]
app_attach_req 29 [ RFC-to-be ]
app_attach_ans 30 [ RFC-to-be ]
unused (was app_attachlite_req) 31 [ RFC-to-be ]
unused (was app_attachlite_ans) 32 [ RFC-to-be ]
config_update_req 33 [ RFC-to-be ]
config_update_ans 34 [ RFC-to-be ]
reserved 0x8000..0xfffe [ RFC-to-be ]
error 0xffff [ RFC-to-be ]

Ninth, in the new registry created in task three above, another new
registry will be created called the "RELOAD Error Code" Registry.

Entries in this registry are 16-bit integers. The registration policy
for this new registry will be Standards Action as defined in RFC 5226.

The initial contents of this registry are:

Error Code Name Code Value Reference
---------------------------------------- ----------------- -----------------
invalid 0 [ RFC-to-be ]
Unused 1 [ RFC-to-be ]
Error_Forbidden 2 [ RFC-to-be ]
Error_Not_Found 3 [ RFC-to-be ]
Error_Request_Timeout 4 [ RFC-to-be ]
Error_Generation_Counter_Too_Low 5 [ RFC-to-be ]
Error_Incompatible_with_Overlay 6 [ RFC-to-be ]
Error_Unsupported_Forwarding_Option 7 [ RFC-to-be ]
Error_Data_Too_Large 8 [ RFC-to-be ]
Error_Data_Too_Old 9 [ RFC-to-be ]
Error_TTL_Exceeded 10 [ RFC-to-be ]
Error_Message_Too_Large 11 [ RFC-to-be ]
Error_Unknown_Kind 12 [ RFC-to-be ]
Error_Unknown_Extension 13 [ RFC-to-be ]
Error_Response_Too_Large 14 [ RFC-to-be ]
Error_Config_Too_Old 15 [ RFC-to-be ]
Error_Config_Too_New 16 [ RFC-to-be ]
Error_In_Progress 17 [ RFC-to-be ]
reserved 0x8000..0xfffe [ RFC-to-be ]

Tenth, in the new registry created in task three above, another new
registry will be created called the "RELOAD Overlay Link" Registry.

Entries in this registry are 8-bit integers. The registration policy for
this new registry will be Standards Action as defined in RFC 5226.

The initial contents of this registry are:

Protocol Code Reference
------------------- ------------ --------------------
reserved 0 [ RFC-to-be ]
DTLS-UDP-SR 1 [ RFC-to-be ]
DTLS-UDP-SR-NO-ICE 3 [ RFC-to-be ]
TLS-TCP-FH-NO-ICE 4 [ RFC-to-be ]
reserved 255 [ RFC-to-be ]

Eleventh, in the new registry created in task three above, another new
registry will be created called the "Overlay Link Protocol Registry".

Entries in this registry are strings. The registration policy for this
new registry will be Standards Action as defined in RFC 5226.

The initial value in this registry is as follows:

Overlay Link Protocol Reference
--------------------- ------------------
TLS [ RFC-to-be ]

Twelveth, in the new registry created in task three above, another new
registry will be created called the "Forwarding Option Registry".

Entries in this registry are 8-bit integers.

The registration policy for this registry is as follows:
Values in this registry between 1 and 127 have a registration policy of
Standards Action as defined in RFC 5226.
Values in this registry between 128 and 254 have a registration policy
of Specification Required as defined in RFC 5226.
The values 0 and 255 are reserved by [ RFC-to-be ].

The initial values for this registry are:

Forwarding Option Code Reference
----------------------- ---- --------------
invalid 0 [ RFC-to-be ]
reserved 255 [ RFC-to-be ]

Thirteenth, in the new registry created in task three above, another new
registry will be created called the "RELOAD Probe Information Type
Registry."

Entries in this registry are 8-bit integers. The registration policy for
this new registry will be Standards Action as defined in RFC 5226.

The initial values for this registry are:

Probe Option Code Reference
----------------------- ---- --------------
invalid 0 [ RFC-to-be ]
responsible_set 1 [ RFC-to-be ]
num_resources 2 [ RFC-to-be ]
uptime 3 [ RFC-to-be ]
reserved 255 [ RFC-to-be ]

Fourteenth, in the new registry created in task three above, another new
registry will be created called the "RELOAD Extensions Registry."

The registration policy for this new registry will be Specification
Required as defined in RFC 5226.

The initial values for this registry are:

Extensions Name Code Reference
-------------------- ------ -----------------
invalid 0 [ RFC-to-be ]
reserved 0xFFFF [ RFC-to-be ]

Fifthteenth, in the Permanent URI Schemes Registry in the Uniform
Resource Identifier Shemes registry located at:

http://www.iana.org/assignments/uri-schemes.html

a new, permanent URI scheme will be registered as follows:

URI Scheme: reload
Description: Reload
Reference: [ RFC-to-be ]

Sixteenth, in the Application Media Types registry located at:

http://www.iana.org/assignments/media-types/application/index.html

a new media type will be registered as follows:

Media subtype: p2p-overlay+xml
Reference: [ RFC-to-be ]

IANA understands that these are the only IANA Actions required upon
approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (REsource LOcation And Discovery (RELOAD) Base Protocol) to Proposed Standard


The IESG has received a request from the Peer-to-Peer Session Initiation
Protocol WG (p2psip) to consider the following document:
- 'REsource LOcation And Discovery (RELOAD) Base Protocol'
  as a 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 2011-07-22. 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.

In particular, this document contains normative references to documents of
lower maturity levels. Two of those documents are not in the downref registry:
RFC 6091 and RFC 6234.

The IESG is interested in community feedback on whether these
downward references are appropriate.

Abstract


  This specification defines REsource LOcation And Discovery (RELOAD),
  a peer-to-peer (P2P) signaling protocol for use on the Internet.  A
  P2P signaling protocol provides its clients with an abstract storage
  and messaging service between a set of cooperating peers that form
  the overlay network.  RELOAD is designed to support a P2P Session
  Initiation Protocol (P2PSIP) network, but can be utilized by other
  applications with similar requirements by defining new usages that
  specify the kinds of data that must be stored for a particular
  application.  RELOAD defines a security model based on a certificate
  enrollment service that provides unique identities.  NAT traversal is
  a fundamental service of the protocol.  RELOAD also allows access
  from "client" nodes that do not need to route traffic or store data
  for others.




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

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


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1191/

1.a) I (David Bryan, as document shepherd) have reviewed the most
recent version of draft-ietf-p2psip-base-15 and found it ready for
publication.

(1.b) The document has had significant WG discussion and review, and
even a few implementations and comments by those reviewers. The chairs
have tapped a number of selected reviewers on previous versions for
reviews.

(1.c) I generally have no broader concerns about review, but there
have been a number of comments raised about the XML included in the
draft. I don’t believe either the editors or those raising the
comments are (or would claim to be) XML experts. It may be useful to
find an XML expert and have a pass over the XML section.

(1.d) I have no specific concerns about this document that the IESG
should be aware of. The following IPR disclosure (not from any of the
editors) claims it applies to this draft, but no specifics of any kind
are specified: https://datatracker.ietf.org/ipr/1191/

(1.e) The WG as a whole has shown strong consensus behind this draft
over a long period.

(1.f) At this point, I am aware of no likely appeals or major objections.

(1.g) I have run IDNits on the document. There are some problems with
references (out of date, references to informational, etc.) and a few
other nits that need to be fixed prior to publication.

(1.h) The references are split. As mentioned above, there are downward
references (presumably to be moved to informative references).

Downref: Normative reference to an Informational RFC: RFC 2818
Downref: Normative reference to an Informational RFC: RFC 3174
Downref: Normative reference to an Informational RFC: RFC 3447
Downref: Normative reference to an Informational RFC: RFC 6091
Downref: Normative reference to an Informational RFC: RFC 6234

(1.i) The document has an IANA considerations section, and appears to
be consistent with the document. There are a considerable number of
IANA registrations proposed in the document. Reasonable names are
suggested for registries.

(1.j) I (and many others) have examined the formal language for the
protocol. I have not personally verified the XML, but as mentioned
above there has been extensive discussion of the XML syntax and it may
be wise to have an expert look at the XML.

(1.k)

Technical Summary
This document defines a protocol to manage a secure Peer-to-Peer
(P2P) Distributed Hash Table (DHT) connection structure for use by
Session Initiation Protocol (SIP) devices which allows these device to
function with minimal central servers. The protocol provides
functionality to allow devices to securely form, join, leave, and
maintain an overlay of peers. It also allows devices to establish
connections between each other, and to collectively augment or replace
the location and connection establishment capabilities of traditional
client-server SIP in a P2P context.

Working Group Summary
This document is a WG document that has WG consensus.

Document Quality
This document has been looked at by many reviewers, including a
number of chair-appointed reviews. While there are still perhaps some
minor editorial issues, the document is of good quality.