[XCON] Should we keep or adjust some of the redundant text in common-data-model?

Robert Sparks <rjsparks@nostrum.com> Fri, 17 June 2011 20:37 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: xcon@ietfa.amsl.com
Delivered-To: xcon@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 820B19E802B for <xcon@ietfa.amsl.com>; Fri, 17 Jun 2011 13:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.767
X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Tf3SjSHgXASJ for <xcon@ietfa.amsl.com>; Fri, 17 Jun 2011 13:37:26 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A25219E8030 for <xcon@ietf.org>; Fri, 17 Jun 2011 13:37:25 -0700 (PDT)
Received: from [] (pool-71-170-49-161.dllstx.fios.verizon.net []) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p5HKbLeA082794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Jun 2011 15:37:21 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
From: Robert Sparks <rjsparks@nostrum.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Jun 2011 15:37:20 -0500
Message-Id: <642D74C0-A298-47E4-A0C2-3819D4E093BD@nostrum.com>
To: xcon@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Received-SPF: pass (nostrum.com: is authenticated by a trusted mechanism)
Cc: pete resnick <presnick@qualcomm.com>, draft-ietf-xcon-common-data-model@tools.ietf.org
Subject: [XCON] Should we keep or adjust some of the redundant text in common-data-model?
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jun 2011 20:37:27 -0000

All -

During IESG evaluation, Pete Resnick observed that common-data-model, ccmp, and the examples document
each had places where the documents repeated each other, and repeated clauses from the documents they
depend on (such as RFC4575) in ways that make the document harder to read and introduce the possibility
of conflict between those documents, especially as they are maintained in the future.

Pete has a concrete suggestion for removing the redundancy in this document in his DISCUSS at
<https://datatracker.ietf.org/doc/draft-ietf-xcon-common-data-model/ballot/>. I would like to confirm that
people have considered the potential for conflict between the documents in the future and want to maintain
the text as it is currently constructed anyhow, or if the changes Pete proposes are acceptable to the group.
Either answer is ok - the point of Pete's DISCUSS is to confirm that the working group has considered this
possibility rather than to insist on a particular change.

Pete's proposal is to completely remove sections like 4.2.2 and 4.2.3 which currently say
> 4.2.2.  <display-text>
>    The <display-text> element is described in section 5.3 of [RFC4575].
> 4.2.3.  <subject>
>    The <subject> element is described in section 5.3 of [RFC4575].
to remove similar sections that copy sentences forward from 4575, like
> 4.2.11.  <service-uris>
>    The <service-uris> describes auxiliary services available for the
>    conference.  The <service-uris> element is described in section 5.3.2
>    of [RFC4575].
(note that that first sentence is also the first sentence of 5.3.2 in 4575),

to avoid things that could be interpreted as clarifications or even updates to 4575, such as the
first sentence of 4.2.10:
> 4.2.10.  <conf-uris>
>    The <conf-uris> element contains the identifiers to be used in order
>    to access the conference by different signaling means. 

and to avoid duplication and some of the coupling with other documents
 throughout the introduction, by removing paragraphs 2, 3, and 4, and the figure.

Please see the link to the discuss text for the full set of proposed changes.

What does the group think?

My 2cents - I agree with the principle behind Pete's suggestion, and I think my first read of the document would have
been smoother without sections like 4.2.2. I think the opportunity for error introduced by drift as the
documents are maintained is very low, but the editorial effort to avoid that risk is also very low.
I am less convinced that the introductory material is redundant and think the coupling with, for instance,
5239 is maintainable going forward.