Re: [Gen-art] Gen-ART review of draft-ietf-mmusic-sdp-media-capabilities-15

[Flemming Andreasen <[e-mail]>]

On 12/12/12 2:13 PM, Alexey Melnikov wrote:
> On 04/12/2012 18:16, Flemming Andreasen wrote:
>> Hi Alexey,
> Hi Flemming,
>> Thank you for your review of the document - comments below:
>>
>> On 11/26/12 7:03 AM, Alexey Melnikov wrote:
>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>> Gen-ART, please see the FAQ at
>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>
>>> Please resolve these comments along with any other Last Call comments
>>> you may receive.
>>>
>>> Document: draft-ietf-mmusic-sdp-media-capabilities-15
>>> Reviewer: Alexey Melnikov
>>> Review Date: 2012-11-26
>>> IETF LC End Date: 2012-11-12
>>> IESG Telechat date: not scheduled
>>>
>>> Summary:  This document is ready for publication as Proposed Standard,
>>> with nits.
>>>
>>> Nits/editorial comments:
>>>
>>> This might be obvious to a SIP implementer, but the media 
>>> type/subtype definition RFC is not referenced anywhere. Should it be?
>>>
>> I don't believe so. The document is an extension of SDP (RFC 4566) 
>> which maintains its own media type name space and registry and hence 
>> it simply follows the rules of SDP (as defined in RFC 4566, which did 
>> change from the old SDP spec defined in RFC 2327).
>>
>> RFC 4288 (which I presume you are referring to here) should not apply.
> I think SDP has to be in agreement with RFC 4288 or we have a bigger 
> problem. In particular media type syntax. But I am Ok with no change 
> in this area.
>>> 3.3.5. The Latent Configuration Attribute
>>>
>>>    Latent configurations may be announced by use of the latent
>>>    configuration attribute, which is defined in a manner very 
>>> similar to
>>>    the potential configuration attribute.  The latent configuration
>>>    attribute combines the properties of a media line and a potential
>>>    configuration.  The media type (mt=) and the transport protocol(s)
>>>    (t=) MUST be specified since the latent configuration is independent
>>>    of any media line present.  In most cases, the media configuration
>>>    (m=) parameter MUST be present as well (see Section 4 for examples).
>>>
>>> This doesn't look like a correct use of MUST, please reword not to 
>>> use any RFC 2119 keyword or at least provide a pointer to a document 
>>> that contains the original requirement.
>> How about this:
>> <quote>
>>           Latent configurations may be announced by use of the latent
>>           configuration attribute, which is defined in a manner very 
>> similar
>>           to the potential configuration attribute. The latent 
>> configuration
>>           attribute combines the properties of a media line and a 
>> potential
>>           configuration. A latent configuration MUST include a media 
>> type (mt=) and a transport protocol configuration parameter
>>       since the latent configuration is independent
>>           of any media line present. In most cases, the media 
>> configuration
>>           (m=) parameter needs to be present as well (see Section 4 
>> for examples).
>> </quote>
> Yes, this is exactly what I had in mind. Thanks.
>>>    The lcfg attribute is a media level attribute.
>>>
>>>  [...]
>>>
>>>    If a cryptographic attribute, such as the SDES "a=crypto:" attribute
>>>    [RFC4568], is referenced by a latent configuration through an acap
>>>    attribute, any keying material required in the conventional
>>>    attribute, such as the SDES key/salt string, MUST be included in
>>>    order to satisfy formatting rules for the attribute.  The actual
>>>    value(s) of the keying material SHOULD be meaningless, and the
>>>
>>> Can you please elaborate on what are you trying to say here?
>>>
>> Is this better:
>> <quote>
>>          If a cryptographic attribute, such as the SDES "a=crypto:"
>>           attribute [RFC4568], is referenced by a latent
>>           configuration through an acap attribute, any keying material
>>           required in the conventional attribute, such as the SDES 
>> key/salt
>>           string, MUST be included in order to satisfy formatting 
>> rules for
>>           the attribute. Since the keying material will be visible 
>> but not actually used at this stage (since it's a latent configuration),
>>       the value(s) of the keying material SHOULD be meaningless, and 
>> the receiver of the lcfg attribute
>>       MUST ignore the values.
>> </quote>
> This is better. I was actually most wondering about the meaning of 
> "meaningless". Did you mean "not a real value you would use for a real 
> exchange"?
Indeed - much better stated that way. I've updated the text accordingly 
and just submitted the updated document. Thanks again for the review and 
comments.

Regards

-- Fleming

>>> receiver of the lcfg attribute MUST ignore the values.
>>> .
> Best Regards,
> Alexey
>
>
> .
>