[Gen-art] RE: gen-art review of draft-ietf-xcon-framework-09.txt

Hi Scott,

Thanks for the review.  I have a few responses embedded below [MB].

Mary. 

-----Original Message-----
From: Scott Brim [mailto:swb@employees.org] 
Sent: Tuesday, October 16, 2007 4:16 PM
To: Gen-ART Mailing List; Barnes, Mary (RICH2:AR00); Chris Boulton; Orit
Levin; Adam Roach; Cullen Jennings
Subject: gen-art review of draft-ietf-xcon-framework-09.txt

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document:	draft-ietf-xcon-framework-09.txt
Reviewer:	Scott Brim
Review Date:	15 Oct 2007
IETF LC End Date:   22 Oct 2007
IESG Telechat date: (if known)

Summary: This draft is ready for publication as a Proposed Standard
         RFC.  I have a couple of comments which should not block it.  

Comments:

  - idnits says:

      == Outdated reference: draft-ietf-simple-message-sessions has
         been published as RFC 4975

      == Outdated reference: draft-ietf-xcon-bfcp-connection has been
         published as RFC 5018

  - As a naive reader, I wonder why this is standards track as opposed
    to informational.  I get the sense that there are external
    reasons.  It is very general.  If I were building a conferencing
    system, I would first start with requirements, then design a
    system to meet those requirements, and then perhaps go back to
    this document to see if I had forgotten anything.  It might help
    me to look through this document during the design phase, just to
    narrow my thinking, but I probably wouldn't want my thinking
    narrowed.  It might help with interoperability, but since it is so
    general it does not really constrain implementors of individual
    components well enough to ensure interoperability.  It feels more
    like a thought document, something the WG would use internally
    while it defined actual specs.  So I wonder why it is not just
    informational, but I believe there are reasons.

[MB] We did debate this in the WG as someone else had the same
suggestion as yourself.  But, it was agreed that the original
deliverable was defined to be standards track, so we kept it that way.
[/MB]

  - Some of the language could be edited for clarity, but that is not
    enough to stop the document since it's not in a protocol
    specification.  For example, "The conference object identifier is
    created both by the conferencing system based on internal actions
    as well as based on specific conference protocol requests.".
[MB] I won't disagree that the wording may be awkward in some places -
partly due to multiple editors and other cases as a result of careful
wording to reflect WG decisions.  I'm hoping that anything really
untoward could be fixed by the RFC editor. But, if you could ship a list
of the worst offenders, I can make a pass through and tidy up before we
progress.  [/MB]

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art