Subject: Re: [Sipping] FW: WGLC Review: draft-ietf-sipping-presence-scaling-requirements-01.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 03 Sep 2008 18:49:12 +0300

Hi,

as you may remember, a while ago, we (i.e., the chairs) asked whether or 
not we should be publishing this RFC. We got off-list and on-list 
feedback stating that this draft was important and that we should 
publish it. However, we did not get any volunteers in addition to Vijay 
to review this draft (its WGLC ends today).

We would like to get two additional reviewers for this draft before 
progressing it further. Note that this is a fairly short draft and that 
reviewing it should not take long.

In short, if you think this draft is important, the best way to state 
your opinion will be to volunteer to review it ;o)

Thanks,

Gonzalo

Mary Barnes wrote:
> Oops!  I didn't have the right title to get this automatically to the
> authors.  Please make sure to incldue the right address in posting any
> comments on this doc (folks will sometimes miss comments if they're only
> sent to the WG mailing list).
> 
> Thanks,
> Mary. 
> 
> ______________________________________________ 
> From: 	Barnes, Mary (RICH2:AR00)  
> Sent:	Wednesday, August 13, 2008 12:37 PM
> To:	[email-masked]
> Cc:	'Gonzalo Camarillo';
> [email-masked]'; simple mailing
> list
> Subject:	WGLC  Review:
> draft-ietf-sipping-presence-scaling-requirements-01.txt
> 
> Hi folks,
> 
> This is to announce a Working Group Last Call on the following document
> to be published as Informational:
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-presence-scaling-
> requirements-01.txt
> 
> The review period will end on 3 Sept 2008 (3 weeks time). 
> 
> Note that I have cross-posted to the SIMPLE WG, but ask that you please
> send your comments only to the SIPPING WG mailing list and authors.
> 
> At this point we only have one reviewer that has volunteered:  Vijay
> Gurbani
> We need at least two others and a presence expert (per RAI review
> process). 
> 
> And, we do encourage others to review and make any final comments on the
> document at this time (including the very useful "Ready" comment). 
> 
> Thanks,
> Mary
> SIPPING WG co-chair
> 
> As a reminder, the SIPPING WG review guidelines are available at:
> https://softarmor.com/sipping/process/wg-review/sipping-review-guideline
> s.html
> 
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 04 Sep 2008 16:42:33 +0100

Hi,

I have a few minor comments/questions.

1. Section 4.1.3 - There is a problem with the text "Operators and
Administrators do not want the users to sometimes not be able to modify
or even see" maybe it should say "Operators and Administrators do not
want the users to be able to modify or even see".

2. Section 5. - I think it is the Subscriber that SHOULD indicate all of
the dataset schemas that is supports by listing all of the MIME types
for the supported datasets in the SUBSCRIBE request header: Accept. Not
the Notifier is this correct ?

3. Section 5.5.1.  The 'visibility' Attribute. Some SIP UA's especially
in the enterprise environment have concepts of users and administrators
and separate access controls for data items. For example a SIP UA may
have separate web pages for administrators and users. If the visibility
attribute is set to "admin" the text states "Display of the property
value may be allowed using special administrative interfaces" so I
assume it could be displayed on the administration web pages. But the
draft says nothing as to whether the property value can be modified
using these special administrative interfaces (E.g. Web Pages). However
the text in 4.1.3 indicates that the access control relates to modifying
the data as well as viewing the data.  There would seem little point in
changing the data on the phone locally if the next time a profile is
downloaded the old value is used again so is some other mechanism needed
to control whether the property value can be modified locally at the UA
?

Regards
Andy

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Mary Barnes
>Sent: 20 August 2008 16:20
>To: [email-masked]
>Cc: Paul Kyzivat; 
>[email-masked]; 
>[email-masked]; Dean Willis
>Subject: Re: [Sipping] Pre-WGLC 
>Review:draft-ietf-sipping-profile-datasets-01.txt
>
>Now with the right title!
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Barnes, Mary (RICH2:AR00)
>Sent: Wednesday, August 20, 2008 10:02 AM
>To: [email-masked]
>Cc: Paul Kyzivat; [email-masked];
>[email-masked]; Dean Willis
>Subject: [Sipping] Pre-WGLC Review:
>
>Hi folks,
>
>This is to announce a PRE Working Group Last Call on the following
>document to be published as Standards Track:
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-profile-
>datasets-
>01.txt
>
>The review period will end on 10 Sept 2008 (3 weeks time).  Please
>ensure that authors are included in either the "To" or "Cc" to ensure
>they see the comments in a timely manner. 
>
>At this point we only have two reviewers that have "volunteered":  Paul
>Kyzivat and Dean Willis (I would like at least 2 others and I 
>have cc'ed
>Paul and Dean, so they can either ACK or NACK this review assignment)
>
>And, we do encourage others to review and make any comments on the
>document at this time, particularly in regards to its readiness for
>WGLC.  While this is a -00 doc, this is by far the oldest document in
>the WG and was very thoroughly reviewed (albeit with a lot 
>more content)
>way long ago, thus we are not doing a typical "Initial Review" for this
>document. 
>
>Thanks,
>Mary
>SIPPING WG co-chair
>
>This list is for NEW development of the application of SIP Use
>[email-masked] for questions on current sip Use
>[email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 19 Sep 2008 12:25:43 +0300

Hi,

the authors are already working on the comments received from Vijay and 
Hisham. In any case, per my email below, we would like to get an 
additional reviewer for this draft. Any volunteers?

Cheers,

Gonzalo

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 19 Sep 2008 13:56:08 +0200

Hi,

A short comment / queston, concerning a scalility requirement:

   o  REQ-007: Presence systems (intra or inter-domain) SHOULD scale in
      linear proportion to the number of watchers and presentities in
      the system.

This requirement takes not into account the relationsship between presentities
And watchers. Meaning for example in adding few presentities with a huge amount of watchers,
This linear proportion can not be achieved. Therefore I think, this has to
Be taken into account in this requirement.

   o  REQ-007: Presence systems (intra or inter-domain) SHOULD scale in
      linear proportion to the number of watchers and presentities in
      the system. Precondition ist that the number of watchers of a presentity and the
      number of precentities a watcher can monitor is restricted.

What do you think about?

Regards
Christian Schmidt

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von ext Gonzalo Camarillo
Gesendet: Freitag, 19. September 2008 11:26
An: Gonzalo Camarillo
Cc: [email-masked]; [email-masked]; Mary Barnes
Betreff: Re: [Sipping] FW:WGLC Review: draft-ietf-sipping-presence-scaling-requirements-01.txt

Hi,

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Sep 2008 09:30:53 -0400

>       number of precentities a watcher can monitor is restricted.

How about:

    o  REQ-007: Presence systems (intra or inter-domain) SHOULD scale in
       linear proportion to the number of watchers and presentities in
       the system, so long as the average number of watchers per
       presentity has a fixed bound.

Namely, its not necessary to bound any particular user's behavior so 
long as the average is fixed rather than proportional to the number of 
presentities.

Over the short term that is likely to be true by accident. Over longer 
periods of time, as the system becomes ubiquitous, the average number is 
likely to rise but maybe not in proportion to the number of users in the 
system.

This behavior could probably be constrained if there was a cost to the 
end user associated with having a buddy.

	Thanks,
	Paul

---

From: [email-masked]
Date: Wed, 24 Sep 2008 10:55:02 -0400 (EDT)

(This is a re-send of a message I sent on 11 Sept.  The original got
caught in a spam trap.)

Draft: draft-ietf-sipping-profile-datasets-01
Reviewer: Dale R. Worley
Review Date: 11 Sept. 2008
Review Deadline: 10 Sept. 2008
Status: pre-WGLC

Summary: This draft is on the right track but has open issues,
described in the review.=20

I have the following major concerns:

1. The draft is not tightly written, in that it talks *about* the user
agent profile dataset system, but it does not carefully define the
system based on prior knowledge.  E.g., several significant terms are
not defined in the glossary; the "application profile" is mentioned in
a few places, but its source and purpose are nowhere described; clear
distinction is not kept between the profile dataset system, the various
profile dataset schemas, and individual profile dataset instances.
All of these problems seem to be of the sort caused by authors who are
so familiar with the subject matter as to be unaware of what the
reader might not know, and could be cured by a careful editing.

2. The intended scope of the RFC is unclear.  One possibility is that
the RFC is intended to be a conceptual guide to the profile dataset
system, giving little more information than that profiles are
separated into datasets and that the UA must merge multiple profiles,
and listing all of the information that must be specified in the
dataset definition RFCs.  If this possibility is chosen, much of the
material in the draft should not be present, as it is long-winded
examples of matters about which the dataset definitions have complete
freedom:  e.g., the allowed value spaces of properties, the common
setting attributes, the merge algorithms.  In short, essentially all
of section 5 should be omitted because it is not normative or binding
on the writer of a dataset definition.

The other possibility (and the one that I vastly prefer) is that the
RFC defines the operation of the profile dataset system clearly enough
that from it one could from it implement a UA profile dataset toolkit,
a toolkit into which one could plug the dataset schemas to produce
(without further programming effort) software that would handle all
the processing that is discussed in the draft.

To implement this second possibility would require that the draft
specify a number of matters that it does not at present specify,
including:

- the datatypes allowed for the settings, and how they are specified
by the dataset schemas

    In particular, the draft seems to envision that all settings are
    either "scalar" datatypes or are subsets of values of a "scalar"
    datatype.  The allowed set of scalar datatypes is not specified.
    (Section 5.12 has a placeholder for this specification.)
    The subset types are not clearly defined, so I'm certain that
    various odd special cases will lead to interoperability problems.
    How the subset types would be specified in the dataset schemas is
    not specified.

- what merge algorithms will be allowed, and how they are to be
specified

    The least desirable choice is that each dataset definition will
    have a free hand to define its merge algorithms in English, as
    that makes it impossible to build a toolkit to handle the merge
    process.  However it seems unlikely that this RFC could specify
    any set of merge algorithms without the danger of omitting some
    algorithm that would turn out to be essential.  One possibility is
    that the specification could define that the merge algorithms are
    to be specified in the schemas using XSLT or another standardized
    language.

In any case, the authors need to decide what the intention of the RFC
is and adjust the text to match.

The remaining two problems are questions regarding the overall data
model used for profile information:  That all the data can be modeled
as triples "schema-URN/setting-name -> scalar value".

3. The handling of non-scalar settings is not clear.  In all UAs that
I know of, some aspects of the configuration information are
conceptually a "structure containing an array of structures".  E.g.,
there are a number of "lines", and for each line, the UA needs a set
of data:  user-part, domain, outgoing-proxy, auth-user, auth-password,
registration-interval, etc.  There is no clear mapping from this
conceptual structure into the datatypes that seem to be envisioned:
named scalars and named sets of scalars.

4. The handling of repeated datasets is not clear.  In the framework,
it seems to be assumed that each of the 4 sources of profiles (user,
application, device, local-network) will provide a set of datasets,
and within each set, no two profiles with have the same schema URN.
The schema URNs allow the UA to determine which datasets are to be
merged with each other, resulting in a set of merged datasets, each of
which has a unique schema URN.  From the merged datasets, datasets
that are not needed by the UA are discarded, and from thost that are
not discarded, the non-supported extensions are discarded.

However this system assumes that it would never be meaningful to have
more than one (merged) dataset with the same schema URN.  In practice,
this means that if a UA can contain an "entity" that is configured by
a dataset, that no UA will ever want to contain more than one entity
of that type, as in that case, there would be no way to provide
configuration to each of the entities separately.  However, this
assumption of no duplication seems (to me) to be unlikely to hold in
practice.

Dale

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 26 Sep 2008 14:58:02 +0200

Hi Paul,

Sorry for the late reply, but the harddisk of my notebook has refused
further service this week.

I like your new version of REQ-007, it covers the point I raises.

A related question: What about Denial of Service attacks? Should we
provide requirements, to restrict the risk of DoS attacks? For example
to restrict the number of watchers per presentity or to restrict the
number of changes in presence status per time-unit?

Regards
Christian 

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: Freitag, 19. September 2008 15:31
To: Schmidt, Christian 1. (NSN - DE/Munich)
Cc: ext Gonzalo Camarillo; [email-masked];
[email-masked]; Mary
Barnes
Subject: Re: [Sipping] FW:WGLC Review:
draft-ietf-sipping-presence-scaling-requirements-01.txt

How about:

system.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Sep 2008 10:41:51 -0400

Christian,

Certainly DoS attacks need to be addressed in practice.
But I question whether they need to be included in the scaling analysis.
Perhaps it would be sufficient to state that the scaling analysis 
assumes the absence of DoS attacks.

Or, I guess, one could assume that in the kind of large scale 
deployments being considered there will *always* be some sort of DoS 
attack, and try to incorporate the cost of coping with that into the 
analysis. But I can't imagine how the statistical characteristics of 
such an attack could be incorporated.

	Paul