Subject: [rtcweb] Updated -gateways draft

From: Harald Alvestrand <[email-masked]>
Date: Tue, 07 Jul 2015 00:19:07 +0200

Uwe and I have prepared a new -gateways draft (version -01).

I don't think there's much controversial in it, and there's only one
issue that I think needs WG time at this time:

Should it be Informational or Standards-track?

An informational document defines guidance for how gateways should
behave, but nobody needs to pay attention if they don't want to.

A standards-track document (which no other RTCWEB document should be
dependent on) defines requirements for how things that call themselves
"WebRTC gateways" should behave, but nobody needs to call their gateways
that, and anyway, there's no protocol police, so the difference isn't
all that much in practice.

More important: What do people want it to be?

Harald

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Jul 2015 15:35:22 -0700

> More important: What do people want it to be?
​I think we adopted it in part because 3GPP had a dependency on it.  Does
it need to be standards track for them to reference it?

Ted​

> Harald
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: [email-masked]
Date: Mon, 13 Jul 2015 22:18:58 -0500

Hi
It would be good if it is a standards track as 3GPP depends on it and 
all implementations would confirm to it . having it as Informational is 
really not of much use.

- Ranjit

On 2015-07-06 5:35 pm, Ted Hardie wrote:
> On Mon, Jul 6, 2015 at 3:19 PM, Harald Alvestrand
> <[email-masked]> wrote:
> 
> ​I think we adopted it in part because 3GPP had a dependency on it.
> Does it need to be standards track for them to reference it?
> 
> Ted​
> 
>> Harald
>> 
>> https://www.ietf.org/mailman/listinfo/rtcweb [1]
> 
> 
> 
> Links:
> ------
> [1] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 14 Jul 2015 08:23:42 +0200

> all implementations would confirm to it . having it as Informational is

Could you share some more detail here?

- What 3GPP spec is depending on it?
- What does the 3GPP spec depend on being in the draft?
- What's the rules for referencing an IETF spec from a 3GPP spec, and
why does the category matter?

Harald

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jul 2015 07:42:04 +0000

Hi,

>> all implementations would confirm to it . having it as Informational 
>> is really not of much use.
>

3GPP TS 24.371

> - What does the 3GPP spec depend on being in the draft?

Currently the spec only says that the eP-CSCF (which is acting as the IMS WebRTC gateway) shall support the functionality in the draft.

So, as far as I know, 3GPP doesn't really rely on anything being in there, because the 3GPP specific procedures are anyway defined in the 3GPP spec. 3GPP only wants the eP-CSCF to be as aligned with a generic gateway as possible.

> - What's the rules for referencing an IETF spec from a 3GPP spec, and why does the category matter?

That question I'll let someone like Keith to answer :)

But, as far as I know, the category as such shouldn't matter - it really depends on how the draft is used. 

Regards,

Christer

>>> dependent on) defines requirements for how things that call 
>>> themselves "WebRTC gateways" should behave, but nobody needs to call 
>>> their gateways that, and anyway, there's no protocol police, so the 
>>> difference isn't all that much in practice.
>>>

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 15 Jul 2015 08:02:25 +0000

Dear All,
some background info:

the 3GPP architecture provides a WebRTC gateway function (since 3GPP Release 12).
The 3GPP WebRTC gateway entity is based on the decomposed gateway model according ITU-T H.248, i.e., H.248 is used as (vertical) gateway control protocol.
The 3GPP WebRTC gateway function is mapped on the existing 3GPP P-CSCF/IMS-ALG entity ("the controller part") and the IMS access gateway ("the media gateway part").
Thus, the 3GPP WebRTC gateway represents actually an "IMS WebRTC gateway" (in Rel-12 and 13).

The 3GPP specs (from WebRTC gateway perspective) are
a) 3GPP 23.334, which covers signalling requirements and procedures for the gateway control interface and
b) 3GPP 29.334, which specifies the protocol solution, known as so called "H.248 profile specification" (in context of H.248).

The 3GPP WebRTC gateway work is complemented by ITU-T SG16, as the technology owner of the H.248 protocol, as responsible instance for the development of H.248 protocol extensions (called H.248 packages).

The associated ITU-T work item is "H.248.WEBRTC", - and there will be a first Recommendation for "H.248 WebRTC gateways" soon, under Rec number ITU-T H.248.94.
The June draft may be found under:
 http://wftp3.itu.int/av-arch/avc-site/2013-2016/1506_Che/TD-11.zip 
The October meeting input for next IETU-T meeting is available (for ITU-T delegates) under:
 https://www.itu.int/md/dologin_md.asp?lang=en&id=T13-SG16-151012-TD-WP1-0278!!MSW-E 

The scope of the ITU-T H.248 WebRTC gateway function is aligned to IETF RTCWEB requirements in order to provide full support from gateway side. Hence, the "ITU-T H.248 WebRTC gateway function" represents currently a superset in comparison to the "3GPP Rel-12/13 IMS H.248 WebRTC gateway function". All major capabilities are supported, but there' are also some differences ...

Harald, draft H.248.94 (H.248.WEBRTC) is already refering to draft-rtcweb-gateways, - because the H.248 WebRTC gateway actually just realizes such a WebRTC gateway entity as outlined by the rtcweb draft.
 
BTW: I'd like to take the chance to point out some gateway specific observations, which should be addressed as well by the gateway draft. See H.248.WEBRTC, Appendix L6 Living List – Distributed Text-over-IP endpoints for WebRTC data 'text'

Coming back to the original question: whether it should be Informational or Standards-track, - I don't know. But it is apparent that both, the 3GPP and ITU-T work on WebRTC gateways needs to be tightly coupled and linked to the IETF gateway draft in my opinion.

Regards,
Albrecht

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Dienstag, 14. Juli 2015 08:24
To: [email-masked]; Ted Hardie
Cc: [email-masked]
Subject: Re: [rtcweb] Updated -gateways draft

Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 15 Jul 2015 10:50:18 +0200

Thank you very much for this information!

It would seem to me to make sense to have an informative reference from
the gateway draft to the H.248.WEBRTC draft, so that people can find a
real worked example of such a gateway.

The text-over-IP specification would seem to require additional work
outside the scope of RTCWEB - this has been discussed before, and the
decision was to declare it out of scope. I think this will be typical
for applications that connect to gateways - they will require more
things than just WebRTC for a complete specification; thus, having the
example to point to is a Good Thing.

Harald

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 15 Jul 2015 09:42:32 -0600

> On Jul 15, 2015, at 2:02 AM, Schwarz, Albrecht (Albrecht) <[email-masked]> wrote:
> 

I'd be happy for Keith to correct me but my understanding is that 3GPP does not really differentiate much on the RFC track and can have normative references to informational RFC.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 15 Jul 2015 19:12:56 +0000

In general, 3GPP can quite happily normatively reference both informational and standards track documents. The key is of course that the referenced material is suitable, i.e. that normatively referenced material is specified in a suitable fashion to be a normative requirements. In previous mails I have given at least one example of such requirements.

However Albrecht does introduce a different complication.

3GPP does also normatively reference ITU-T documents for the H.248 functionality, and if the ITU-T documents need then to normatively reference the IETF document to support that, then if I recall correctly, ITU-T does require that to be a standards track document.

What is clear is that we will have a mixture of normative material and informational material. It is important that that distinction is clear. If that is so, what is the issue with having a standards track document?

Keith 

> From: rtcweb [mailto:[email-masked]] On Behalf Of 
> Cullen Jennings
> Sent: 15 July 2015 16:43
> To: Schwarz, Albrecht (Albrecht)
> Cc: [email-masked]
> > On Jul 15, 2015, at 2:02 AM, Schwarz, Albrecht (Albrecht) 
> <[email-masked]> wrote:
> > 
> > Coming back to the original question: whether it should be 
> Informational or Standards-track, - I don't know. But it is 
> apparent that both, the 3GPP and ITU-T work on WebRTC 
> gateways needs to be tightly coupled and linked to the IETF 
> gateway draft in my opinion.
> 
> I'd be happy for Keith to correct me but my understanding is 
> that 3GPP does not really differentiate much on the RFC track 
> and can have normative references to informational RFC. 
> 
>

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 16 Jul 2015 06:50:19 +0000

I could clarify the situation for Draft ITU-T H.248.94 (ex H.248.WebRTC):

=> the reference to draft-rtcweb-gateways is INFORMATIVE only, and there isn't any real need for a normative reference because the scope of this ITU-T Recommendation is on "H.248 profile GUIDELINES"

("That's the reason why draft-rtcweb-gateways is listed in the Bibliography section.")

-Albrecht

-----Original Message-----
From: DRAGE, Keith (Keith) 
Sent: Mittwoch, 15. Juli 2015 21:13
To: Cullen Jennings; Schwarz, Albrecht (Albrecht)
Cc: [email-masked]
Subject: RE: [rtcweb] Updated -gateways draft

Keith 

> From: rtcweb [mailto:[email-masked]] On Behalf Of Cullen 
> Jennings
> Sent: 15 July 2015 16:43
> Informational or Standards-track, - I don't know. But it is apparent 
> that both, the 3GPP and ITU-T work on WebRTC gateways needs to be 
> tightly coupled and linked to the IETF gateway draft in my opinion.
> 
> I'd be happy for Keith to correct me but my understanding is that 3GPP 
> does not really differentiate much on the RFC track and can have 
> normative references to informational RFC.
> 
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 17 Jul 2015 06:13:40 +0530

Hi all,

The main intent of this draft is to define WebRTC gateway entity in IETF
itself as there are lot of discussions wherein it is not clear which WebRTC
entity under discussion. This draft has to be in standards track as the
draft relax some of the normative statements of WebRTC endpoint namely

1) ICE-lite
2) Non-bundle SDP support only
3) No need of TURN support
4) No need to support data channel.

These information are clarified in Sec 2 of the -gateways draft. Of course,
these relaxation has some impact in other WebRTC endpoints as well. The
example is to support non-bundle SDP in the incoming offer to the WebRTC
endpoint.

Of course, we may see more in the relaxation list as the other RTCWeb drafts
are yet to be matured as RFC. As Keith mentioned, some of the normative text
is required in this draft. IMO, the standards track looks more appropriate
for this draft.

Thanks
Partha

> From: rtcweb [mailto:[email-masked]] On Behalf Of Schwarz,
> Albrecht (Albrecht)
> Sent: Thursday, July 16, 2015 12:20 PM
> To: DRAGE, Keith (Keith); Cullen Jennings
> Cc: [email-masked]
> => the reference to draft-rtcweb-gateways is INFORMATIVE only, and
> there isn't any real need for a normative reference because the scope
> of this ITU-T Recommendation is on "H.248 profile GUIDELINES"
> 
> In general, 3GPP can quite happily normatively reference both
> informational and standards track documents. The key is of course that
> the referenced material is suitable, i.e. that normatively referenced
> material is specified in a suitable fashion to be a normative
> requirements. In previous mails I have given at least one example of
> such requirements.
> 
> 3GPP does also normatively reference ITU-T documents for the H.248
> functionality, and if the ITU-T documents need then to normatively
> reference the IETF document to support that, then if I recall
> correctly, ITU-T does require that to be a standards track document.
> 
> What is clear is that we will have a mixture of normative material and
> informational material. It is important that that distinction is clear.
> If that is so, what is the issue with having a standards track
> document?
> 
> Keith
>