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

["Livingood, Jason" <[e-mail]>]

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
>