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

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

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?