Subject: Re: [Speermint] AD review: draft-ietf-speermint-architecture-16.txt

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 15 Dec 2010 22:15:35 +0000

Responses inline below. There is only one open question for you and I can
update the I-D.

- Jason

On 11/17/10 8:40 AM, "Gonzalo Camarillo"
>Title: I leave it up to the editors whether or not they want to expand
>the acronym SPEERMINT. Given that it is exanded in the Introduction,
>it should probably be expanded also in the title.

Done. Changed it to "Session PEERing for Multimedia INTerconnect
Architecture" 

>
>First sentence in the Abstract and first sentence in the Introduction:
>
>s/it's/its/

correction made

>
>First paragraph in the Introduction:
>
>"...of a SIP Service providers [RFC5486] network."
>
>It should be Provider's. Also, when capitalizing Provider, expand the
>SSP acronym there, and not in the next sentence.

Both corrections made.

>When the reader reaches Figure 1, there are a lot of new
>acronyms. Having a terminology section after the Introduction would
>help readers understand the figure. Otherwise, readers need to consult
>other RFCs or check the meaning of the acronyms later in this
>document.

While we'd prefer to stick with the reference to the terminology
document (RFC 5486) noted at the top of the figure (that document was
quite difficult to finalized), I have included a brief terminology section
before Figure 1 that defines each of the key terms.

>Acronyms such as UA should also be expanded on their first use or
>added to the Terminology section.

Correction made.

>Section 3. Why is the sending of the BYE (step 5) more likely to be
>performed by the target SSP than by the originating SSP?

It just seemed logical as we envisioned the call flow between two people
in our head. 

QUESTION: Would you like a modification there?

>Section 5.1.1.2
>
>s/chosen for based on/chosen based on/

correction made

>
>Section 5.1.2:
>
>"not all of them may be used". Does this mean that the LRF MUST NOT
>use all of them or that the LRF does not need to necessarily use all
>of them?

It means that the sections that follow (5.1.2.1 - 5.1.2.3) are typical
parts of the LRF but that based on the considerations of each SSP, that
particular SSP may not implement all of them (and it is not an RFC 2119
statement).

>
>Section 5.1.3
>
>   When communicating with another SSP, entities compliant to this
>   document should select a TLS-protected transport for communication
>   from the originating (or indirect) SSP to the receiving SSP if
>   available, as described further in Section 5.2.1.
>
>This "should" sounds like a normative SHOULD. If this normatively
>defined somewhere else (i.e., in another document)?
>
>In general, there are a set of instructions that are given without
>using normative language. What is the intention of those instructions?

This is intended to be information and to use non-normative language.
While words like "should" are still appropriate, they are not 2119-style
words, and as such we have removed any reference to 2119.

>
>ID nits gives the following warning:
>
> == Unused Reference: 'I-D.ietf-speermint-voip-consolidated-usecases' is
>     defined on line 609, but no explicit reference was found in the
>     text

We thought it was a good informative reference for further reading. I have
added text to that effect in the next version to clear the nit check.

Jason

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 16 Dec 2010 11:05:35 +0200

Hi Jason,

thanks for addressing my comments. When you submit the new revision I
will take care of starting its IETF LC.

> QUESTION: Would you like a modification there?

well, this is a small detail, so I leave it up to you whether or not you
want to state that step 5 is likely to be performed by the target SSP or
that it can be performed by either of them.

I have not seen any statistics about who is more likely to hang up when
involved in a call, the callee or the caller. However, in the PSTN, the
terminating switch will not send a REL even if the callee hangs up. This
allows the callee to hang up, move to another telephone, and pick up
there in order to continue the conversation (i.e., the single line
extension service). So, at least in the PSTN, you are much more likely
to see REL messages in the caller to callee direction.

In any case, as I said before, this is a minor point. We have probably
already spent to much time on it :o)

Thanks,

Gonzalo

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 20 Dec 2010 21:55:43 +0000

The new updated draft (-17) has now been published (notification should
hit the list shortly).

BTW, I also updated section 3 to note that parties are equally likely to
perform the BYE.

Regards
Jason