Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
draft-ietf-p2psip-service-discovery-15

[Ballot comment]
  Since RedirServiceProvider records are expiring and registrations are
  being refreshed periodically, there can be certain rare situations in
  which a service lookup may fail even if there is a valid successor
  present in the ReDiR tree.  An example is a case in which a ReDiR
  tree node is fetched just after a RedirServiceProvider entry of the
  only successor of k present in the tree node has expired and just
  before a Store request that has been sent to refresh the entry
  reaches the peer storing the tree node.  In this rather unlikely
  scenario, the successor that should have been present in the tree
  node is temporarily missing.  Thus, the service lookup will fail and
  needs to be carried out again.

Why not just require that the node registering a service update its entry in the service table at some fraction of the expiry time, rather than after it has expired or when it expires?  E.g., 90%, or 50%, or something like that.

[Ballot comment]

- 4.3 step 5 - this implies that anyone can rewrite the Redir
information for anyone else. Is that right? If so, why is that
ok? I do see section 5, but I didn't get how that really works
- can you explain? (To someone who's forgotten RELOAD mostly;-)

- ISTM that the first sentence of section 9 is contradicted by
the 2nd paragraph of section 9. I'd say just delete the first
sentence there. (As noted by others.)

- WRT the secdir review, I'm not sure SHA-1 is ok for the
access control policy - can you explain why it is? (If we
assume SHA-1 is broken for collisions.)

[Ballot discuss]
Three points to discuss, please:

1. As Adrian points out, the terminology reference, p2psip-concepts, needs to be normative, if you really are using terminology thence.

2. As Adrian also points out, you're doing things here that have to create new security considerations.  In fact, in the very next paragraph after you say it doesn't, you say that this creates a new access control policy.  Is there really nothing at all to consider with respect to Section 5?

3. In Section 4.4, can you give at least some guidance about what "periodically" might mean?  You say that it's up to each service provider to determine, but how can they determine that without at least a few words about the considerations involved, the issues that might come up, the tradeoffs, the consequences of choosing a time period that's too short or too long?  Could I decide that, say, 20 years might be a suitable lifetime?

[Ballot comment]
I was surprised that I could follow all of this document. Good job by
the authors!

I have no objection to its publication, but I note a couple of points
below that I think could improve the document. I shouldn't be surprised
if the Security ADs pounce on something similar to the last point.

---

The scaling problem described in Section 1 is real in as much as it is
clearly a problem that deteriorates in a linear fashion with the number
of services. Furthermore, the problem worsens in the product of the
number of services and the number of nodes making discovery requests.

This is all as described in the text.

What is missing, however, is an explanaiton of why this is perceived to
be a problem that needs to be solved. For example, if there is only
ever going to be one service provided by one server, and only five nodes
requesting the service then clearly nothing sophisticated is needed. The
text in this section calls out four example services which suggests to
the naif reader that growth to twelve service types might not be
unreasonable. No clue is given as to the size of the cohort requesting
discovery, nor to the multiplicity of service-providing nodes.


It might, therefore, be interesting to enhance this section with some
clues about current expectations of scaling requirements and also with
an observation that we usually under-estimate scaling requirements in
the Internet.

---

If this document uses terminology from [I-D.ietf-p2psip-concepts], don't
I need to read that document to understand this one? If so, that makes
it a normative reference.

---

In Section 4.5 the following text was slightly confusing...
      The
      fetched tree node is then analyzed and the next action determined
      by checking conditions 1-3.
...because (I think) this text is embedded in condition 1 of the 3
conditions.

Perhaps "...by checking the three conditions set out here" or even
"...MUST determine the next action by starting to check the conditions
listed here starting at condition 1."

Or maybe I was just confused and the text is OK :-)

---

Why are there no security considerations? You are using existing
(securable) protocol mechanisms to achieve a new function. Attacks on
service discovery are likely to have "interesting" effects either
denying services or redirecting traffic requesting a service to a
false server. That means that you have defined some new threats
(including, I think, the fact that requesting service discovery reveals
a certain amount of information about the requester).

Surely you need to describe these threats and explain how existing
security mechanisms in the protocol are adequate protection.

[Ballot comment]
In this text appearing in 4.5.  Service Lookups

  1.  If there is no successor of node n present in the just fetched
      ReDiR tree node (note: within the entire tree node and not only
      within the current interval) responsible for I(level,n.id), then
      the successor of node n must be present in a larger segment of
      the identifier space (i.e., further up in the ReDiR tree where
      each interval and tree node covers a larger range of the
      identifier space).  Therefore, node n MUST reduce the current
      level by one to level=level-1 and carry out a new Fetch operation
      for the tree node responsible for n.id at that level.  The
      fetched tree node is then analyzed and the next action determined
      by checking conditions 1-3.

I'm guessing that "conditions 1-3" mean "this paragraph and the two following", but I'm guessing. If I'm guessing right, I wish that could be clearer ... perhaps it would help to label the three conditions as "Condition 1/2/3"?

In this text appearing in 4.6.  Removing Registrations

  Before leaving the RELOAD Overlay Instance, a service provider MUST
  remove the RedirServiceProvider records it has stored by storing
  exists=False values in their place, as described in [RFC6940].

Am I remembering that these records are soft state and will time out and be removed eventually anyway? If I'm remembering correctly, I'm wondering if this needs to be a MUST, or if it's just good advice.

IESG/Authors/WG Chairs:

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

IANA's reviewer has the following comments/questions:

See questions associated with ACTION 3 and ACTION 4.

ACTION 1:

Upon IESG approval, IANA will register the following in the RELOAD Access Control Policies registry (see http://www.iana.org/assignments/reload):

NODE-ID-MATCH  [this RFC]


ACTION 2:

Upon IESG approval, IANA will register the following in the IETF XML ns registry (see http://www.iana.org/assignments/xml-registry):

urn:ietf:params:xml:ns:p2p:redir
[this RFC]


ACTION 3:

Upon IESG approval, IANA will register the following in the RELOAD Data Kind-ID registry (see http://www.iana.org/assignments/reload):

Value TBD  REDIR  [this RFC]

QUESTION: This document requests value 104 (and should note that this is a suggested value, as IANA can't guarantee that this value will still be available when the IESG approves the document). The registry presents values in hex. Do you want value 0x104, or 0x68?


ACTION 4:

Upon IESG approval, IANA will create the following registry in an as-yet-TBD location:

Registry Name: ReDiR Namespaces
Reference: [this RFC]
Registration Procedure(s): ???

Namespace  Reference
turn-server  [this RFC]
voice-mail    [this RFC]

QUESTION: What's the registration procedure for this registry? See RFC5226 for examples.

QUESTION: Should this registry be created at an existing URL, like http://www.iana.org/assignments/reload, or at a new one? If the latter, what's the title of the page? (The name should reflect whether other registries might be placed there in the future.) For a list of existing registries and categories, please see http://www.iana.org/protocols.


Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

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


The IESG has received a request from the Peer-to-Peer Session Initiation
Protocol WG (p2psip) to consider the following document:
- 'Service Discovery Usage for REsource LOcation And Discovery (RELOAD)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-07-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  REsource LOcation and Discovery (RELOAD) does not define a generic
  service discovery mechanism as a part of the base protocol.  This
  document defines how the Recursive Distributed Rendezvous (ReDiR)
  service discovery mechanism used in OpenDHT can be applied to RELOAD
  overlays to provide a generic service discovery mechanism.




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

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


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

Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
(draft-ietf-p2psip-service-discovery-11)

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

Proposed Standard

Why is this the proper type of RFC?

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

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

Yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:

The document defines how to apply the Recursive Distributed Rendezvous (ReDiR)
service discovery mechanism used in OpenDHT in RELOAD to provide a generic
service discovery mechanism. ReDiR implements service discovery by building a
tree structure of the service providers that provide a particular service. The
tree structure is stored into the RELOAD Overlay Instance using RELOAD Store
and Fetch requests.

Working Group Summary:

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

Document Quality:

The document was thoroughly reviewed by Marc Petit-Huguenin and Carlos J.
Bernardos. Joscha Schneider also reviewed it by doing a basic implementation of
the mechanism described in the document.

Personnel:

Who is the Document Shepherd?

Carlos J. Bernardos

Who is the Responsible Area Director?

Alissa Cooper

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

The Document Shepherd has personally done a thorough review of the document.
Some changes (mainly editorial) were requested to the authors and included in
the last revision of the draft. The Document Shepherd believes the document is
ready for forwarding to IESG for publication.

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

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

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

A review of Section 8 was requested and provided by the APPS area (Martin
Thomson).

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

The Document Shepherd has no such concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

Yes.

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

No.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

There is WG consensus behind this document.

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

No.

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

The idnits tool returns: 1 error (1 instance of too long lines in the document);
1 warning (it does not seem to be really a problem, but reducing the identation
in Section 4.1 might solve the previous error; 6 comments (none of them seems
to be a problem).

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

The document meets the review criteria.

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

Yes.

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

No.

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

No.

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

No.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

The document introduces one additional access control policy to the "RELOAD
Access Control Policy" Registry and one additional data Kind-ID to the
"RELOAD Data Kind-ID" Registry. These registry are described in
[RFC6940].

The document also requests the IANA to create a "ReDiR Namespaces" Registry. A
detailed specification of the initial contents for the registry is provided.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

No formal language segments exist.