Re: [bfcpbis] Documentation structure for bfcpbis

(As an individual)
Please see comments inline.

> -----Original Message-----
> From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On
> Behalf Of DRAGE, Keith (Keith)
> Sent: Thursday, January 05, 2012 6:27 AM
> To: bfcpbis@ietf.org
> Subject: [bfcpbis] Documentation structure for bfcpbis
> 
> (As WG cochair)
> 
> I'd like to initiate some discussion on the documentation structure of
> what we want produce in the bfcpbis working group.
> 
> There have been a couple of comments on rolling into the existing BFCP
> RFC and we have at least a few options round here. Here at least are a
> few thoughts:
> 
> What
> ----
> 
> As a working group we have at least a couple of issues to address:
> 
> -	identify what we want in terms of compatibility with the
existing
> BFCP (at the moment I am assuming that any new implementation would
> interoperate with the existing BFCP at least using TCP, but we have
not
> had a discussion on that)

I agree. To date, we have not specified any changes to the RFC 4582
specification when using TCP. Based on discussion at IETF 82, we planned
to change the BFCP protocol version number from 1 to 2 when using UDP
per RFC 4582-bis, but there was no decision on what to do when using
TCP. To date, I do not see any need to specify version 2 when using TCP.

> -	identify the best way of presenting the material that works for
> people doing completely new implementations versus thus updating
> existing implementations.
> 
> If we need to be able to identify differences there are a number of
> ways of doing this including: 1) rely on the difference tools at
> tools.ietf.org and ensure that any WG output produces a true
difference
> to the existing RFC, 2) carry forward any differences to the existing
> RFC in an annex or appendix (with the main body being the full text)
> and 3) keep the document solely as a difference document. There is of
> course a fourth option of ignoring identifying any differences at all.

The changes to date have been specific to UDP, and I anticipate that any
changes applicable to TCP will be minimal and not require any
restructuring of the existing BFCP RFCs. As such, I think we will
eventually be able to roll the set of differences captured in the WG
draft into an updated version of RFC 4582. This being the case, option 1
is my preference.

> When
> ----
> 
> We also have options in terms of when we change the document to
> whatever format we decide. We could do it immediately, or we could
> progress through the working group discussion and WGLC on the existing
> structure and only make the change at, for example, publication
> request. Doing the latter would focus the working group on changing
> only those bits that meet completing the immediate charter of the
> working group, but may be more difficult to work with. Doing the
former
> may open up the working group to addressing a complete second edition,
> with any number of miscellaneous enhancements to the existing BFCP.

I think the sooner the better. Once the set of changes seems stable,
perhaps based on draft-ietf-bfcpbis-rfc4582bis-00, we could make the
change in format.  

> RFC 4583
> --------
> 
> The text we are working on also contains changes to RFC 4583
(currently
> owned by MMUSIC).
> 
> I am assuming that we would probably want to keep the current scope
> split (because MMUSIC need to review and agree any SDP changes), but
> would want to handle a bis version in the same manner as the main BFCP
> document. However the floor is open to discussion.

I agree. Currently, the differences are captured in
draft-sandbakken-dispatch-bfcp-udp-03, and will continue to be covered
in draft-ietf-bfcpbis-rfc4582bis-00. This facilitates covering all the
changes in one draft, but we should work with MMUSIC on relocating the
SDP related changes into either a draft-ietf-bfcpbis-rfc4583bis or
draft-ietf-mmusic-rfc4583bis draft at the same time we switch
draft-ietf-bfcpbis-rfc4582bis from being a difference based draft.

Cheers,
Charles

> Discussion
> ----------
> 
> I'd like to give a period of time to discussion of the best way
forward
> on the issues above, with the aim of identifying what options people
do
> want on the table when I start a more formal consensus call in say a
> weeks time (or however long it takes the discussion to complete).
> 
> So please put your views on the table as regard to what I written
> above, and also make sure that if you prefer something else, that you
> have identified it. Also if you think any approach is a non-starter,
> now would be good to identify it and we'll eliminate it from any
> consensus call (for reasons of keeping the final call simpler).
> 
> Regards
> 
> Keith
> 
> P.S. And just to repeat - none of this precludes raising any technical
> discussion on the document (as separate threads please).
> 
> 
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis