Shepherd writeup
draft-chz-simple-cu-separation-bng-protocol-06

draft-chz-simple-cu-separation-bng-protocol has been presented for
publication as an Informational RFC on the Independent Submissions
Stream.

The document describes a protocol that has been implemented and deployed
but the Abstract and Introduction make it very clear that this is not an
IETF solution.

There should rightly be some concern that this work is in conflict with
work being carried out in the Broadband Forum (BBF). Indeed, when this
work was discussed at the BCAUSE BoF at IETF-104 the general view was
that the IETF should "hold off" doing further work in the area until the
BBF had completed its work on an architecture and requirements for a
protocol solution - such completion was predicted 'by the end of
September 2019'.

The authors have, I think, despaired of this work being progressed in 
the IETF in the near future. And, since they are describing a multi-
vendor solution that other vendors may wish to participate in, and which
other operators may want to consider deploying, this seems a reasonable 
candidate for publication in the Independent Submissions Stream.

Two further relevant points:

- The authors indicate that they would be supportive of the IETF
  deciding that they wanted to work in this area and would be willing 
  for their work to form the basis of that work even if it resulted in
  very significant changes to what they have documented.

- The authors (after discussion with the ISE and the RTG AD responsible
  for the BCAUSE BoF) have included a paragraph in the Introduction to
  point the reader at the ongoing work in the BBF.

This draft was first presented to the ISE at revision -03. Since then,
it has been reviewed by the ISE, and by three reviwers. We were all
fairly agressive on the technical details and this caused several
revisions to the draft. The reviews were sufficiently detailed and
comprehensive that including them here would be excessive - they are
available on request.

A note on IANA:
  This document does not make any requests for IANA action. As a new
  protocol obviously specifies many code points: these have been 
  documented as if in an IANA considerations section, but without asking
  IANA to take any action. This should make it easy for readers to
  quickly find and understand code points.

A note on IPR:
  Slightly to my surprise, no IPR has been discolsed against this draft.
  I have checked this with the authors, and they confirm that no IPR
  needs to be disclosed.


Back