Re: [P2PSIP] Ben Campbell's Yes on draft-ietf-p2psip-sip-20: (with COMMENT)

["Thomas C. Schmidt" <[e-mail]>]

Hi Ben,

thanks for the feedback. Please see inline.

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm balloting "yes" because I want to see this move forward, but I have a
> number of comments and questions:
>
> Substantive:
>
> - Figure 1: It might be helpful to show the R-URI in the INVITE.
>

Mhmm, not sure. This would IMO break the storytelling which focuses on 
the interplay of RELOAD and remaining protocol operations.

> - 1, 2nd to last paragraph: Please add a citation for GRUU.
>

O.K. - was already in the refs, now at this para, too.

> - 3.3, 7th paragraph from end: "any peer SHOULD verify
>     that the AOR of the request is a valid Resource Name with respect to
>     its domain name "
> How does that differ from the MUST in the first bullet, below?

One peer is the requester (the SHOULD), the other peer is the storing 
peer (the MUST). The storing peer is the entity that persists an entry 
in the overlay and MUST check and ensure its consistency.

> Also, does
> SIP over reload support phone numbers? If so, it would be good to include
> some discussion about how phone numbers fit into the domain scheme. If
> no, then please say so explicitly.
>

This is basically the question whether AORs containing telephone numbers 
correspond to valid rfc822Name in X509v3 certificates, which I suppose 
they do.

We've added to the first para of Section 1:

    This document defines a SIP Usage of RELOAD that allows SIP [RFC3261]
    user agents (UAs) to establish peer-to-peer SIP (or SIPS) sessions
    without the requirement for permanent proxy or registration servers,
    e.g., a fully distributed telephony service. This service transparently
    supports SIP addressing including telephone numbers.

> -3.3, 3rd and 4th paragraph from end:
> What certificate? (Probably covered in RELOAD, but a comment here would
> be helpful.)
>

That's the basic RELOAD certificates from the enrollment server. It has 
been introduced already in the terminology Section 2.

> - 3.4, first paragraph:
> The "MAY" looks like a statement of fact. I suggest "might"
>

This very section describes how to restrict the overlay domains - in 
this sense, the MAY is a statement about the protocol (distr. system) 
mechanism and should be a MAY, I suppose. It is a precise operational 
option.

> - 3.4, fourth paragraph:
> That seems to say that "enable=false" means the restrictions are enabled.
> Is that the intent?
>

What is intended:

  If a <domain-restrictions> element is present, then these restrictions 
apply. Further rules can be enabled. Without further rules (or 
inconsistent parameters), domain names are restricted to those that that 
match the domain name of the overlay.

> - 4.1, 2nd and 3rd paragraphs from end:
> Does that mean normal SIP procedures should be used if no overlay is
> found for the domain, or that normal SIP procedures can be used instead
> of checking for other overlays?
>

Normative language has been taken out here following a comment of Spencer.
The described case is "you query the wrong overlay, so we give some 
hints on what else
you could do".

> What about the case where the domain is supported by the overlay, but the
> AOR is not found? Should the caller check for other overlays, or switch
> to standard SIP?
>

That's the point "AOR domain is hosted in overlay?" - if the AOR is not 
present, the requester may search for other contacts supporting this 
domain name.

> - 5.1, 2nd paragraph:
> Are SIPS over reload connections assumed to be e2e encrypted? The last
> sentence says that ordinary SIPS requires e2e encryption, which is simply
> not true.

Yep, this has been already corrected after a comment from Spencer: see 
Version 20.

> What are "client links"?
>

Client links are RELOAD-defined links from clients (not member of the 
overlay) to the overlay.

> - 5.1, 3rd paragraph, last sentence:
> does "redirect its communication path" mean redirect to classic SIP?
>

That refers to the normal SIP contact header field operations. The user 
can announce an alternate contact point, which may be accessible via 
classical SIP.

> - 6, first paragraph: "Globally Routable User Agent URIs (GRUUs)
> [RFC5627] have been
>     designed to allow direct routing without the indirection of a SIP
>     proxy function. "
> That’s not really true. 5627  section 3.4 talks about using the proxy to
> dereference a gruu.
>

O.K., let's rephrase like this:

    Globally Routable User Agent URIs (GRUUs) [RFC5627] have been
    designed to allow direct routing to a specific UA instance
    without the need for dereferencing by a domain-specific SIP
    proxy function.

That should hit the key of GRUUs.

> - 8.1, first paragraph: "Hence no
>     extra burden is introduced for RELOAD peers beyond loads already
>     present in the base protocol."
> What about from when a caller chooses to switch to conventional SIP to
> reach a callee with a domain not supported by the overlay?
>

Not sure I understand: a caller using conventional SIP would not ask for 
assistance by RELOAD peers??

> - 8.2.4: Can you cite something for these methods that exist?
>

Well, one P2P anonymity service would be TOR. Here P2P pseudonym 
services are more interesting, but I don't see any IETF work ... various 
references in the scientific literature exist, but discussing this would 
IMO really lead away from the document.

> Editorial:
>
> - IDNits has some comments marking code blocks. The data structure in 3.2
> seems to qualify.
>
> -2 : It would have been useful to mention that you are intentionally
> dropping the AoR schemes back at the first AoR example.
> Otherwise SIP people are going to be confused until they find the comment
> 5 pages in.
>

This is already mentioned in the Terminology Section 2.

> - 3.1, first paragraph: "a UA registers its AOR and location"
> technically, the user’s AOR and the UAs network location.
>

O.K., fixed.

> - 3.2, 3rd bullet in first bullet list:
> It's a bit premature to use the term Callee. Perhaps Registrant?
>

O.K., fixed.

> - 4.2, step 3:
> What is an "external AoR"?
>

Those that are not associated to members of the overlay.

> - Appendix A: Why is this not in the main body?
>

This is a forward pointer to a mechanism beyond the scope of this 
document (incl. the use of SHARE).

Thanks again,

  Thomas
-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °