Hi,
These are good points thanks you. I tried to clarify the algorithm in
the next version of the draft. I'm proposing the text
The node first determines the overlay name. This value is provided
by the user or some other out of band provisioning mechanism. The
out of band mechanisms may also provide an optional URL to the
enrollment server but this is NOT RECOMMENDED. If a URL to the
enrollment server is not provided, the node MUST do a DNS SRV query
using a Service name of "p2p_enroll" and a protocol of tcp to find
an
enrollment server and form the URL by appending a path of "/p2psip/
enroll" to the overlay name. For example, if the overlay name was
example.com, the URL would be "https://example.com/p2psip/enroll";.
Once an address and URL for the enrollment servers is determined,
the
peer forms an HTTPS connection to that IP address. The certificate
MUST match the overlay name as described in [RFC2818]. Then the
node
MUST fetch a new copy of the configuration file. To do this, the
peer performs a GET to the URL. The result of the HTTP GET is an
XML
configuration file described above, which replaces any previously
learned configuration file for this overlay.
On May 4, 2009, at 1:15 , JeffreyHo wrote:
Dear all,
I have some questions about the content of 10.2 discovery through
enrollment server in RELOAD Base. Could someone please give me answer?
(1) According to the following paragraphs in 10.2. Discovery
Through Enrollment Server,
The peer first determines the overlay name. This value is provided
by the user or some other out of band provisioning mechanism.
If the name is an IP address, that is directly used otherwise the
peer
MUST do a DNS SRV query using a Service name of "p2p_enroll" and
a protocol of tcp to find an enrollment server.
Is the overlay name here equivalent to the attribute 'instance-name'
in the overlay configuration? If yes, but why this paragraph say "
If the name is an IP address, that is directly used "? It seems the
name means the location of the enrollment server not overlay
instance-name. It makes me confused.
(2) According to 10.1. Overlay Configuration, it said that The file
can contain multiple "configuration" elements where each one
contains the configuration information for a different overlay. In
addition, in 10.2. Discovery Through Enrollment Server, it said
that the peer performs a GET to the URL formed by appending a path
of "/p2psip/enroll" to the overlay name. For example, if the
overlay name was example.com, the URL would be "https://example.com/p2psip/enroll
".
My question is below.
If an single enrollment server maintains two different overlays,
named exam1.com and exam2.com, which have two separated
"configuration" elements in the same overlay configuration file,
this single enrollment server must be able to accept the GET request
both https://exam1.com/p2psip/enroll and https://exam2.com/p2psip/enroll
" from some peers for different overlay. Is such concept right? If
right, how does this enrollment sever be implemented?
Any comment and answer will be appreciated.
Thanks a lot in advance.
BR,
Jeffrey
本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內
容，並請銷毀此信件。
This email may contain confidential information. Please do not use
or disclose it in any way and delete it if you are not the intended
recipient.
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
