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

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-p2psip-sip-20: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/



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

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

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

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

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

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

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

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?

- 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.
What are "client links"?

- 5.1, 3rd paragraph, last sentence:
does "redirect its communication path" mean redirect to classic 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.

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

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

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.

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

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

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

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

[Thomas C. Schmidt]

Hi Ben,

thanks for the feedback. Please see inline.

Post by Ben Campbell
----------------------------------------------------------------------
----------------------------------------------------------------------
I'm balloting "yes" because I want to see this move forward, but I have a
- 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.

Post by Ben Campbell
- 1, 2nd to last paragraph: Please add a citation for GRUU.

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

Post by Ben Campbell
- 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.

Post by Ben Campbell
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.

Post by Ben Campbell
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.

Post by Ben Campbell
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.

Post by Ben Campbell
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.

Post by Ben Campbell
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".

Post by Ben Campbell
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.

Post by Ben Campbell
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.

Post by Ben Campbell
What are "client links"?

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

Post by Ben Campbell
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.

Post by Ben Campbell
- 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.

Post by Ben Campbell
- 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??

Post by Ben Campbell
- 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.

Post by Ben Campbell
- 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.

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

O.K., fixed.

Post by Ben Campbell
It's a bit premature to use the term Callee. Perhaps Registrant?

O.K., fixed.

Post by Ben Campbell
What is an "external AoR"?

Those that are not associated to members of the overlay.

Post by Ben Campbell
- 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

[Ben Campbell]

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

Post by Thomas C. Schmidt
Hi Ben,

Post by Ben Campbell
- 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?

[...]

Post by Thomas C. Schmidt

Post by Ben Campbell
- 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"?

Post by Thomas C. Schmidt

Post by Ben Campbell
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.
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:+***@example.com;user=phone" map to
"+***@example.com"?

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.

Post by Thomas C. Schmidt

Post by Ben Campbell
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?

Post by Thomas C. Schmidt

Post by Ben Campbell
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?

Post by Thomas C. Schmidt

Post by Ben Campbell
That seems to say that "enable=false" means the restrictions are enabled.
Is that the intent?

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

Post by Thomas C. Schmidt

Post by Ben Campbell
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?

Post by Thomas C. Schmidt

Post by Ben Campbell
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:***@example.com". I am attached to an overlay that
claims to support "example.com". I look for "***@example.com", 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:***@example.com 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?
[...[

Post by Thomas C. Schmidt

Post by Ben Campbell
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".

[...]

Post by Thomas C. Schmidt

Post by Ben Campbell
- 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.

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

Post by Thomas C. Schmidt

Post by Ben Campbell
- 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?

Post by Thomas C. Schmidt

Post by Ben Campbell
- 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 "***@dht.example.com". 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.

Post by Thomas C. Schmidt

Post by Ben Campbell
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.