Re: [MMUSIC] Feedback on draft-boucadair-mmusic-altc-04 as Independent Submission

[Brett Tate <[e-mail]>]

> Notice that this draft has been sent directly to the RFC Editor for
> publication in the Independent Stream. This means that it can only be
> published as Informational or Experimental.
> 
> Additionally, MMUSIC has been requested for comments, but bear in mind,
> that this document is not the produce of the IETF.

I agree.  My mentioning of "standard track" and "no IETF working group is willing to work on the draft" was mostly just an attempt to reconcile why an Informational draft defines a new option-tag even though IANA (per RFC 3261 and RFC 5727) may disallow registering/reserving the new option-tag.  As highlighted within IETF 77 minutes (and thread http://www.ietf.org/mail-archive/web/mmusic/current/msg09016.html) the attempts to get MMUSIC to adopt altc or other ICE alternatives (for IPv4/IPv6 transition) have failed.

For what it's worth, I'd actually prefer that the new option-tag be removed from the draft since it is mostly only a hint and complicates things for some B2BUA/3PCC situations.  However as indicated, the draft is an independent submission.  Thus, my preference is likely of little value unless the new option-tag prevents the draft from becoming an RFC (and becoming an RFC continues to be preferred by the authors).


> On 03/04/2012 15:30, Brett Tate wrote:
> > The functionality provided by draft-boucadair-mmusic-altc is useful.
> I prefer that this draft progress to be an RFC.  It should progress as
> standard track; however publishing as Informational is adequate
> (especially if can reserve the "altc" option-tag) if no IETF working
> group is willing to work on the draft.
> >
> > If the option-tag issue causes concern, it currently appears to
> provide little value other than a hint.  Thus, it could be removed or
> uselessly communicated by other means (such as defining a "ns-
> supported" header to mean the same thing as "supported" when non
> standard track).