[P2PSIP] Spencer Dawkins' Yes on draft-ietf-p2psip-sip-19: (with COMMENT)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-p2psip-sip-19: 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:
----------------------------------------------------------------------

This was a bit confusing to me.

AOR domain not supported by overlay? If the domain part of the AOR
is not supported in the current overlay, the user SHOULD query the
DNS (or other discovery services at hand) to search for an
alternative overlay that services the AOR under request.
Alternatively, standard SIP procedures for contacting the callee
SHOULD be used.

If you don't query the DNS (or other discovery services), and you don't
use standard SIP procedures, are there any other choices? With both of
these being SHOULDs, a conformant implementation might not do either of
them. Is that expected?

If you need this to be RFC 2119 language, I'm guessing this would be
"MUST either do X or Y", but I'm not sure it needs to be RFC 2119.

If you really do need two alternative SHOULDs, it's not required to
explain why a SHOULD is not a MUST, but since the goal is that an
implementer is making an informed choice, helping the implementer
understand why one might not want to do what one SHOULD do is usually
helpful.

I think that

A callee MAY choose to listen on both
SIP and SIPS ports and accept calls from either SIP schemes, or
select a single one.

is using "SIP schemes" generically, but this might be clearer if you just
said "either scheme".

I'm not on top of SIPS these days, but I didn't think

SIPS requires end-to-end protection that may include client links and
endpoint certificates.

was "end-to-end protection". Is it? I thought that it was
protected-hop-by-protected-hop. Or maybe you only mean SIPS in P2PSIP?

Sorry if I'm confused (and the SIP Forum will be thrilled to hear this,
if I'm just confused).

I can figure out what "fork explosion" and "fork bomb" are, but are these
terms in common usage in the SIP community? Is there a definition or
reference for them?

[Thomas C. Schmidt]

Hi Spencer,

many thanks for the feedback - please see inline.

Post by Spencer Dawkins
----------------------------------------------------------------------
----------------------------------------------------------------------
This was a bit confusing to me.
AOR domain not supported by overlay? If the domain part of the AOR
is not supported in the current overlay, the user SHOULD query the
DNS (or other discovery services at hand) to search for an
alternative overlay that services the AOR under request.
Alternatively, standard SIP procedures for contacting the callee
SHOULD be used.
If you don't query the DNS (or other discovery services), and you don't
use standard SIP procedures, are there any other choices? With both of
these being SHOULDs, a conformant implementation might not do either of
them. Is that expected?
If you need this to be RFC 2119 language, I'm guessing this would be
"MUST either do X or Y", but I'm not sure it needs to be RFC 2119.
If you really do need two alternative SHOULDs, it's not required to
explain why a SHOULD is not a MUST, but since the goal is that an
implementer is making an informed choice, helping the implementer
understand why one might not want to do what one SHOULD do is usually
helpful.

I see - the normative SHOULDs appear indeed a bit strong. The described
case is "you query the wrong overlay, so we give some hints on what else
you could do".

Suggested rephrase:

AOR domain not supported by overlay? If the domain part of the AOR
is not supported in the current overlay, the user MAY query the
DNS (or other discovery services at hand) to search for an
alternative overlay that services the AOR under request.
Alternatively, standard SIP procedures for contacting the callee
might be used.

O.K.?

Post by Spencer Dawkins
I think that
A callee MAY choose to listen on both
SIP and SIPS ports and accept calls from either SIP schemes, or
select a single one.
is using "SIP schemes" generically, but this might be clearer if you just
said "either scheme".

O.K., done.

Post by Spencer Dawkins
I'm not on top of SIPS these days, but I didn't think
SIPS requires end-to-end protection that may include client links and
endpoint certificates.
was "end-to-end protection". Is it? I thought that it was
protected-hop-by-protected-hop. Or maybe you only mean SIPS in P2PSIP?

oops, that's a lapse. It should be all links including client links (if
present). So we propose to rephrase

SIPS requires protection of all links that may include client links
(if present) and
endpoint certificates.

Post by Spencer Dawkins
Sorry if I'm confused (and the SIP Forum will be thrilled to hear this,
if I'm just confused).
I can figure out what "fork explosion" and "fork bomb" are, but are these
terms in common usage in the SIP community? Is there a definition or
reference for them?

I could not find a document defining exactly these terms (or
equivalents), but the phenomena are broadly discussed (e.g. RFC 5393).
I'm happy to rephrase, if there is a term striking better - any suggestions?

Thanks again,

thomas

[Spencer Dawkins at IETF]

Hi, Thomas,

Post by Thomas C. Schmidt
Hi Spencer,
many thanks for the feedback - please see inline.

Post by Spencer Dawkins
----------------------------------------------------------------------
----------------------------------------------------------------------
This was a bit confusing to me.
AOR domain not supported by overlay? If the domain part of the AOR
is not supported in the current overlay, the user SHOULD query the
DNS (or other discovery services at hand) to search for an
alternative overlay that services the AOR under request.
Alternatively, standard SIP procedures for contacting the callee
SHOULD be used.
If you don't query the DNS (or other discovery services), and you don't
use standard SIP procedures, are there any other choices? With both of
these being SHOULDs, a conformant implementation might not do either of
them. Is that expected?
If you need this to be RFC 2119 language, I'm guessing this would be
"MUST either do X or Y", but I'm not sure it needs to be RFC 2119.
If you really do need two alternative SHOULDs, it's not required to
explain why a SHOULD is not a MUST, but since the goal is that an
implementer is making an informed choice, helping the implementer
understand why one might not want to do what one SHOULD do is usually
helpful.

I see - the normative SHOULDs appear indeed a bit strong. The described
case is "you query the wrong overlay, so we give some hints on what else
you could do".
AOR domain not supported by overlay? If the domain part of the AOR
is not supported in the current overlay, the user MAY query the
DNS (or other discovery services at hand) to search for an
alternative overlay that services the AOR under request.
Alternatively, standard SIP procedures for contacting the callee
might be used.
O.K.?

Yes, and you might even substitute "might" for the remaining MAY.

Post by Thomas C. Schmidt
I think that

Post by Spencer Dawkins
A callee MAY choose to listen on both
SIP and SIPS ports and accept calls from either SIP schemes, or
select a single one.
is using "SIP schemes" generically, but this might be clearer if you just
said "either scheme".

O.K., done.
I'm not on top of SIPS these days, but I didn't think

Post by Spencer Dawkins
SIPS requires end-to-end protection that may include client links and
endpoint certificates.
was "end-to-end protection". Is it? I thought that it was
protected-hop-by-protected-hop. Or maybe you only mean SIPS in P2PSIP?

oops, that's a lapse. It should be all links including client links (if
present). So we propose to rephrase
SIPS requires protection of all links that may include client links
(if present) and
endpoint certificates.
Sorry if I'm confused (and the SIP Forum will be thrilled to hear this,

Post by Spencer Dawkins
if I'm just confused).
I can figure out what "fork explosion" and "fork bomb" are, but are these
terms in common usage in the SIP community? Is there a definition or
reference for them?

I could not find a document defining exactly these terms (or equivalents),
but the phenomena are broadly discussed (e.g. RFC 5393). I'm happy to
rephrase, if there is a term striking better - any suggestions?

I really like those terms. Could you add a phrase to define them? Perhaps,
"an attack using SIP forking to amplify the effect on the intended victim",
or some such?

(I think "amplify" might be more common in other communities, but I really
do like your terms. Somewhere, Dean Willis is smiling)

Post by Thomas C. Schmidt
Thanks again,
thomas

Oh, thank you. I was hoping I remembered this much of P2PSIP!

Spencer