Subject: [bfcpbis] Documentation structure for bfcpbis

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 5 Jan 2012 15:26:39 +0100

(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)

-	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.

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. 

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.

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).

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 6 Jan 2012 09:41:53 -0800

(As an individual)
Please see comments inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of DRAGE, Keith (Keith)
> Sent: Thursday, January 05, 2012 6:27 AM
> To: [email-masked]
> 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
> ----
> 
> -	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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Tom Kristensen <[email-masked]>
Date: Tue, 24 Jan 2012 15:53:05 +0100

Inline.

> TCP. To date, I do not see any need to specify version 2 when using TCP.

Since no changes have been proposed for TCP/BFCP, incrementing the
protocol version to indicate usage of RFC4582bis UDP/BFCP seems to be
a good path forward.

> draft into an updated version of RFC 4582. This being the case, option 1

This is my preference too. The draft is currently structured as a
'diff' for RFC4582bis and RFC4583bis.

We may add a new section/subsection with a guide to what's new to
assist people implementing the entire new RFCs or actually people
wanting to add UDP/BFCP support to an existing TCP/BFCP
implementation.

> perhaps based on draft-ietf-bfcpbis-rfc4582bis-00, we could make the

As requested by Keith Drage, the -00 version (submitted today) has
only editorial changes and serves as a basis WG document for further
work. I'd like the -01 version to be a proper RFC4582bis, i.e. merging
in the changes and polishing the format.

-- Tom

[...]

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [email-masked]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/