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

["Ben Campbell" <[e-mail]>]

Hi, thanks for the response. Also see inline; I will remove sections 
that do not seem to need further discussion.

On 20 Apr 2016, at 4:47, Thomas C. Schmidt wrote:

> Hi Ben,
>
>> 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.
>

That's your choice to make, but part of the reason I mentioned it was 
because I thought that very interplay was unclear, especially around the 
idea of schemeless AoRs. Should I assume the SIP INVITE is normal SIP, 
and prefixes the AoR with "sip:", "sips", etc in the r-uri?

[...]

>
>> - 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.

The distinction in the text is subtle. Maybe this is a bit of RELOAD 
terminology that I missed, but is the "storing peer" different than the 
"peer that issues a Store request to the overlay"?

>
>> 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.
>

I think it may be more complicated than that. Phone numbers do not 
typically have domains. So more to the point, does this support TEL 
URIs? I think the answer is probably no, and that phone numbers are 
probably only supported by having AoRs where the local part of the 
coincidentally looks like a phone number.

This brings up another question that may already be answered, but if it, 
I don't remember. Are URI parameters allowed? (e.g. does 
"sip:[e-mail];user=phone" map to 
"[e-mail]"?

This all probably doesn't matter as long as we are talking about reload 
AoRs, but it may matter if reload UAs need to interact with legacy SIP.


>> -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.

Let me rephrase the question: A certificate that represents what? The 
user associated with the AoR?

>
>> - 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.

A 2119 "MAY" usually represents an implementation choice. I don't think 
that's what we are talking about here. To illustrate the point, would it 
be reasonable for implementors to write software that did not allow the 
overlay to restrict domain names?

>
>> - 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.

I went back and re-read the section several times. I _think_ it means 
the following:

- If an <domain-restriction> element without "enable=true" exists, then 
the domains are limited to the overlay's own domain.
- If <domain-restriction> is present with enable=true. then the child 
<pattern> elements define the restrictions.

This seems to me to be an odd design choice, and i think implementers 
are going to get confused about the meaning of "enable". It also leaves 
open the possibility of having "enable=true" but know <pattern> 
elements. The text does not seem to define meaning for that situation. 
If I had to guess, I would guess that means the same as when 
enable=false.

So, does "enable" really mean anything beyond "check for pattern 
elements"?

>
>> - 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".

Do you mean that the language in version 19 is a result of Spencer's 
comment, or that the next version will be different due to a comment 
from Spencer?


>
>> 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.

I'm not sure I understand your answer. Imagine I have a user agent that 
can do SIP over Reload, and also normal SIP. Someone hands me a business 
card with "sips:[e-mail]". I am attached to an overlay that 
claims to support "example.com". I look for "[e-mail]", but 
don't find it. (Perhaps my overlay has been misconfigured to think it 
supports "example.com".) Would it make sense for me to then try to send 
an INVITE to sips:[e-mail] using normal SIP processing? (That 
is, outside of the overlay?)

Along these lines, did I miss guidance about making sure an overlay 
doesn't hijack other people's domains? (I see 8.2.3 talks about AoR 
misuse by an attacker, I think this is different. Maybe the enrollment 
service prevents that?
>
>> - 5.1, 2nd paragraph:

[...[

>
>> What are "client links"?
>>
>
> Client links are RELOAD-defined links from clients (not member of the 
> overlay) to the overlay.
>

I understand what a reload "client" is. I don't find the term "client 
link" in 6940. I assume from your answer you mean link in the "network 
connection" sense and not something along the lines of a "hypertext 
link".

[...]


>
>> - 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.

That's still not correct. GRUUs have nothing to do with "direct 
routing". Now, it's entirely possible that being correct here isn't 
important. But I would suggest language more like:

   "... have been designed to allow SIP requests to be addressed to a 
specific UA instance."

>
>> - 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??

If a reload user agent has the ability to redirect to classical SIP, 
does that "import" security considerations from classical SIP?

>
>> 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.

My comment is _about_ section 2 :-) My point is, section _1_ talks about 
AoRs of the form of "[e-mail]". A SIP person reading this 
will be immediately confused, and think that this is not a valid SIP 
AoR. They won't learn that this is intentional until several pages 
later.

>
>> - 4.2, step 3:
>> What is an "external AoR"?
>>
>
> Those that are not associated to members of the overlay.
>

It would be helpful to say that, either here or in the terms section.