P2PSIP IETF73 Wednesday November 19, 2008
Session Notes
Brian Rosen & David Bryan chairs
Note Well Reviewed
Agenda reviewed and accepted
Bruce Lowekamp reviewed
draft-ietf-p2psip-base-00.txt draft
Split
into several categories:
Easy changes since Dublin
splitting base and sip usage
removing http-base error codes
split Ping into Ping and Probe
routing discussion moved to appendix
added discussion of periodic vs. reactive recovery
minor change to finger stabilization
updated IANA consideration
Medium
issues from the list:
no tunnel uses case
given, so it will be removed from the base
decouple overlay
description from enrollment server; change accepted
relaxed wording on
finger table entry selection to allow other topology awareness; this has been
made possible but no
more complicated mechanisms will be required.
Hard issues:
Architecture issue: clarifying how
routing layer and forwarding layer are described.
Unable to
identify "standard" terminology--link vs. transport (architecture vs.
implementer). A suggestion was given to standardize these,
but Bruce cannot find a trulycommon set of
terms. Discussion over the terms
resulted in an agreement that the current document's terminology and diagram is
acceptable, if not perfect
Stat was introduced; it is like fetch,
but retrieves meta-data (length, storage time, lifetime).
mDNS was removed
because it was not likely to be done soon; it is now close to done. Shall it go back in? Hum was yes; James Woodyatt has agreed to review text in this section when it
is restored.
TCP-Test. Proposal to add an
unsecured test transport for early development and interop. This would enable certain kinds of interop testing and sniffing. This does not work if TLS is the only way to
do this. Proposals: do nothing, or make
TLS requirement an overlay policy issue.
The group discussed this, with major arguments discussing whether there
were specific non-test requirements and whether the loss of security in
authentication will create long term problems.
The chairs called for consensus; consensus for retaining TLS as the only
mechanism. It will be confirmed on list.
Large Messages. The current document needs to be revised to
handle end-to-end transport. Options: support large messages as part of base
protocol; provide infrastructure (e.g. error codes & overlay policy), but
not specify details; others? The group
discussed the options. There seemed to
be agreement to provide support for error codes, but leave further work for
later.
AttachLite: previous consensus was to remove ICE, making
ICE-lite required.
This didn't work when the authors tried it. Instead they created an AttachLite
method that establishes connection using only raw transport; this can be used
in overlays known not to have NATs. Public
nodes can implement regular Attach without candidate gathering and interopate with NATed nodes. Review requested, and feedback on potential
replacement ideas.
Support: agnostic security for unknown
kind ideas. We will have to decide
requirements on the list. Vidya says that this is a general issue: the store semantics says you must support all
the kinds of methods in order to accept data.
Is there a more modular approach?
Also, what happens to heterogeneous usage in the overlay. She feels we should separate overlay
primitives from usages. Overlay layer
versus usage layer discussion will be taken to the list.
The group them
moved to discuss NodeFetch
Motivation includes diagnostics,
administration, and service discovery and placement. They discussed the
existing storefetch being reused with this in mind;
another option is to do a probe, followed by Request to Node-ID, but this fails
when the overlay is unstable. Bruce then
reviewed the NodeFetch operation (NodeFetch,
NodeStore, NodeRemove). There were several comments in the room on
the complexity here, and further discussion is expected on the list.
The group then heard Jiang XingFeng discuss the direct response and relay peer draft. He first goes through the discussion of
history; originally proposed in SEP, then mentioned at the Dublin IETF. This is a revision and clarification of those
discussions. This is an optional
enhancement to enable optimization when overlays have high churn or transaction
with large hop counts. The sending peer
decides which routing mode
is used first. The decision can be made based on probes or
past experiences.
NAT Behavior Discovery; this includes a
new message rm_test, with a destination possibly determined by intermediate
nodes. Is this text that gets added to
base draft? Discussion of follow-on
focused on the question of whether the work would go forward, with the discussion
of how many documents to do it being deferred.
First hum: whether or not we
include direct routing as an option in the protocol (not worrying about what
draft): result was consensus for
including it in the protocol. Second
question: do we know enough yet to make
the other decisions (e.g. relay peers and discovery)? There seemed to be no objection to continuing
list discussion, rather than deciding today.
Dan York then presented the p2psip
security draft.
Early conversations with potential concerns
from customers; this current draft is merger of two previous documents. The work planned for the document: synchronize with the RELOAD updates; improve
readability, add a section on interconnecting P2PSIP networks to other
networks.
Open Issue #1: Should this be a separate draft? Should it be merged it into the base?
Partially merge it into the base? Split
out the requirements, with a BCP flavor?
One follow-up question to that was: what
pieces are we really missing here?
For those not addressed in reload, there
are some aspects that would need to be addressed. Vidya asked that
the draft include a threat analysis. Discussion on document and structure and
needed elements resulted in agreement that the authors will re-spin the
document to include the threat analysis and security considerations as one
item; the chairs will work with all authors to determine the number the
document. The second piece will be a
general background information and analysis--it will either be a separate
informational document or put into an existing document (e.g. concepts). The discussion of which document is deferred.
Roni Even then
presented the p2psip diagnostics document on behalf of the authors. First reviewed the changes, then discussed
the diagnostic scenarios. Some are in
the routing protocol; some monitor the overall health of the network; and
lastly diagnostics for a single node.
Open issues: Should we extend Ping? Should we extend Route_Query?
Concerns with making Ping arbitrarily
extensible, and some preferences expressed for introducing one or more new
methods for this. Hum for creating a
working group item: no opposition, and
consensus for adoption.