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

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 3 Apr 2012 14:35:14 +0200

This mail is related to draft-boucadair-mmusic-altc-04.txt, available at:

http://datatracker.ietf.org/doc/draft-boucadair-mmusic-altc/

This draft has been submitted to the RFC Editor for publication in the 
independent submission stream. Because of this, it can be published as 
either Informational or Experimental RFC.

The RFC Editor, in these cases, gets feedback from the community about 
the possible publication, including consultation to the IESG (see RFC 5742).

We would like to get your input, basically, indicating whether you are OK 
with the publication of this Informational/Experimental RFC or whether 
you have concerns. We will try to have a consolidated set of comments to 
the RFC Editor.

The draft proposes a mechanism to include several IP addresses related to 
the same media stream in an SDP offer, including alternative IPv4 and 
IPv6 addresses.

The draft presents a problem: it defines a SIP option tag. SIP option 
tags can only be defined in standards track RFCs (See RFC 3261 Section 
19.2), but this document can only be Informational or Experimental.

Please let the mailing list know your thoughts.

BR,

           Flemming and Miguel (chairs)
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Brett Tate <[email-masked]>
Date: Tue, 3 Apr 2012 06:30:22 -0700

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

Thanks,
Brett

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 4 Apr 2012 12:20:08 +0200

Hi Brett.

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.

/Miguel

On 03/04/2012 15:30, Brett Tate wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Brett Tate <[email-masked]>
Date: Wed, 4 Apr 2012 05:42:27 -0700

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

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