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

[Christian Groves <[e-mail]>]

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:
> On 11/14/13 9:41 AM, Christer Holmberg wrote:
>> Hi,
>>
>>> I don't understand the point of this.
>>>
>>> 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.
>
> 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
>
>> Regards,
>>
>> Christer
>>
>>
>>> 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ä: [e-mail] [mailto:[e-mail]]
>>> Puolesta Christian Groves
>>> Lähetetty: 15. lokakuuta 2013 3:05
>>> Vastaanottaja: [e-mail]
>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>