Subject: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05]

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Nov 2013 23:08:04 +0000

Hi,

Based on the comments from Christian, I suggest the following new text for BUNDLE:

-----------------------------

6.2.2.  Connection Data (c=)

   The "c=" line nettype value [RFC4566] associated with each "m=" line
   within a BUNDLE group MUST be 'IN'.

   The "c=" line addrtype value [RFC4566] associated with each "m=" line
   within a BUNDLE group MUST be 'IP4' or 'IP6'.  The same value MUST be
   associated with each "m=" line within a BUNDLE group.

   NOTE: Extensions to this specification can specify usage of the
   BUNDLE mechanism for other nettype and addrtype values than the ones
   listed above.

-----------------------------

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Christian Groves
Lähetetty: 15. lokakuuta 2013 3:05
Vastaanottaja: [email-masked]
Aihe: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05

Hello Christer,

The SDP grouping mechanism can be applied to different nettype/addrtypes. The BUNDLE draft appears to define behaviour related only to the nettype=IN and addrtypes=IPv4/IPv6. i.e. section 2 defines BUNDLE terminology based on IP.

Is there an intention that the BUNDLE mechanism is only used for the above net and addrtypes? If so should it be mentioned somewhere in the applicability statement?

Regards, Christian

On 14/10/2013 10:37 PM, Christer Holmberg wrote:
>
> Hi,
>
> I've submitted a new version of the BUNDLE draft.
>
> I have implemented the modified text for the Offerer and Answerer 
> procedures, as presented on the list in September.
>
> The procedures now also mention the usage of the SDP 'bundle-only' 
> attribute. However, the attribute definition itself has yet not been 
> added to the draft, as we still haven't solved the issue regarding 
> usage of port zero.
>
> In addition, there are some reference corrections, and the FQDN values 
> in the examples are now according to RFC 2606.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 13 Nov 2013 13:40:14 +1100

Hello Christer,

It looks OK to me.

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Nov 2013 08:52:11 -0800

I don't understand the point of this.

I'm not aware of any general use of a nettype other than IN, or an 
addrtype other than IP4 or IP6, but I also don't see why the behavior of 
bundle is dependent upon this.

Any other choices that still have a notion of port sufficient to allow 
SDP O/A rules to apply should also work with bundle.

So I see no reason to incorporate such a scope limitation.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2013 17:41:44 +0000

Hi,

>I'm not aware of any general use of a nettype other than IN,

RFC 3108 defines an 'ATM' value.

draft-ietf-mmusic-sdp-cs defines a 'PSTN' value.

> or an addrtype other than IP4 or IP6, but I also don't see why the behavior of bundle is dependent upon this.

RFC 3109 defines 'NSAP', 'E164' and 'GWID' values.

draft-ietf-mmusic-sdp-cs defines an 'E164' value.

(Whether the semantics of the two 'E164' values are the same I don't know, but that's a separate issue).

> Any other choices that still have a notion of port sufficient to allow SDP O/A rules to apply should also work with bundle.

I see no reason to require an extension in such cases - especially since they are very unlikely to occur.

Regards,

Christer

> Aihe: Re: [MMUSIC] Draft new version: 
> draft-ietf-mmusic-sdp-bundle-negotiation-05
>
> Hello Christer,
>
>> In addition, there are some reference corrections, and the FQDN 
>> values in the examples are now according to RFC 2606.
>>
>> Regards,
>>
>> Christer
>>
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2013 17:46:11 +0000

I see no reason to NOT require an extension in such cases, that is.

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Christer Holmberg
Lähetetty: 14. marraskuuta 2013 19:42
Vastaanottaja: Paul Kyzivat; [email-masked]
Aihe: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05]

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Nov 2013 10:57:33 -0800

> I see no reason to require an extension in such cases - especially since they are very unlikely to occur.

This is more of a philosophical issue - whether to say as little as 
possible, and allow the scope to be broad, or say extra to narrow the 
scope to the specific case that has motivated the work.

I favor saying nothing about this, and leaving the scope to include any 
network and address type. You are preferring to narrow it. I can live 
with whatever the consensus is.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2013 22:45:46 +0000

Hi,

> This is more of a philosophical issue - whether to say as little as possible, and allow the scope to be broad, or say extra to narrow the scope to the specific case that has motivated the work.
>
> I favor saying nothing about this, and leaving the scope to include any network and address type. You are preferring to narrow it. I can live with whatever the consensus is.

Open Issue #14.

The clarification/restriction was requested by Christian, and personally I think it is good. But, as always, community decides :)

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Fri, 15 Nov 2013 09:58:03 +1100

Hello Paul,

The problem is that BUNDLE is described in terms of how it relates to IN 
addresses not other address types. If the scope is left general the text 
and procedures should also be made general to match. I don't think we 
want to go down that path.

Regards, Christian

On 15/11/2013 5:57 AM, Paul Kyzivat wrote:
>>> or an addrtype other than IP4 or IP6, but I also don't see why the 
>>> behavior of bundle is dependent upon this.
>>
>>> Any other choices that still have a notion of port sufficient to 
>>> allow SDP O/A rules to apply should also work with bundle.
>>
> I favor saying nothing about this, and leaving the scope to include 
> any network and address type. You are preferring to narrow it. I can 
> live with whatever the consensus is.
>
>     Thanks,
>     Paul
>
>> Regards,
>>
>> Christer
>>
>>
>>> The SDP grouping mechanism can be applied to different 
>>> nettype/addrtypes. The BUNDLE draft appears to define behaviour 
>>> related only to the nettype=IN and addrtypes=IPv4/IPv6. i.e. section 
>>> 2 defines BUNDLE terminology based on IP.
>>>
>>> Is there an intention that the BUNDLE mechanism is only used for the 
>>> above net and addrtypes? If so should it be mentioned somewhere in 
>>> the applicability statement?
>>>
>>> Regards, Christian
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Nov 2013 07:07:26 -0800

> want to go down that path.

Hmm. I guess you are referring to the definitions of Unique address and 
BUNDLE address that reference IP address. And maybe 5-tuple and other 
places that refer to "address".

OK. I agree that it may be easier to restrict the scope than to 
wordsmith these definitions to be more general.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Nov 2013 17:51:24 +0000

Hi,

Thanks, Paul!

So, unless someone else objects, I'll include the suggested text in the next version of BUNDLE.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Paul Kyzivat
Lähetetty: 15. marraskuuta 2013 17:07
Vastaanottaja: [email-masked]
Aihe: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05]

On 11/14/13 2:58 PM, Christian Groves wrote:
> Hello Paul,
>
> The problem is that BUNDLE is described in terms of how it relates to 
> IN addresses not other address types. If the scope is left general the 
> text and procedures should also be made general to match. I don't 
> think we want to go down that path.

Hmm. I guess you are referring to the definitions of Unique address and BUNDLE address that reference IP address. And maybe 5-tuple and other places that refer to "address".

OK. I agree that it may be easier to restrict the scope than to wordsmith these definitions to be more general.

	Thanks,
	Paul

>>>> Is there an intention that the BUNDLE mechanism is only used for 
>>>> the above net and addrtypes? If so should it be mentioned somewhere 
>>>> in the applicability statement?
>>>>
>>>> Regards, Christian
>>>>
>>>>> attribute. However, the attribute definition itself has yet not 
>>>>> been added to the draft, as we still haven't solved the issue 
>>>>> regarding usage of port zero.
>>>>>