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

[Paul Kyzivat <[e-mail]>]

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

> 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
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>