Subject: [Speermint] Normative language in draft-ietf-speermint-requirements-02

From: "Elwell, John" <[email-masked]>
Date: Wed, 01 Aug 2007 11:48:13 +0100

In an earlier message
(http://www1.ietf.org/mail-archive/web/speermint/current/msg02064.html)
I commented, amongst other things, on the normative language (RFC2119)
in the requirements draft, and suggested that, if the document does
indeed specify requirements on SSPs, then the normative language should
reflect that. This would be in contrast to most requirements documents
from the IETF, which specify requirements on future IETF work (e.g., on
protocols, architecture) and therefore use normative language in a
different way (e.g., "It MUST be possible to ...", "The mechanism SHOULD
provide a means to....", "The solution MUST NOT permit....").

I raised this again during our meeting in Chicago, and it seemed from
the discussion there that this draft is intended to place requirements
on further work by the SPEERMINT group, and therefore normative language
should reflect that. Consequently any statements that appear to place a
requirement on an SSP should receive some attention.

Looking again at the draft, much of the draft seems to be written in a
way that is inconsistent with the view that emerged from the meeting. In
particular the Abstract and Introduction position the draft as a BCP for
service providers.

So I think we need to establish exactly what the purpose of the document
is.

John

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 13 Aug 2007 11:20:00 +0200

> provide a means to....", "The solution MUST NOT permit....").

:-)

I made the same assumption last year.

> So I think we need to establish exactly what the purpose of the document

My recollection from last year's meetings is that this document is
supposed to document what SSPs must support to do SIP peering.

I have to admit that I never understood what goal this document is
supposed to achieve. A SIP profile document would indeed be helpful,
but for that the title is misleading.

The other problem I have with this document is that the "requirements"
documented there are neither "sufficient" nor "necessary". (From a 
mathematical/logical point of view, conditions have to be either to
be meaningful.)

These requirements are not "sufficient", as they don't imply that all
SSPs which fulfill these requirements are in fact peering with each
other, are willing to do so, or are even able to do so (for number-based 
calls).

Nor are these requirements "necessary" in the sense that whenever
peering is taking place, these requirements are met. There are a number
of peering operational now which do not conform to this list.

The only point I can see in this document is as a guideline for SSPs for
selecting technology partners and/or products. For that, too, it is
misnamed.

/ol
-- 
/ Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /