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

From: Flemming Andreasen <[email-masked]>
Date: Tue, 04 Dec 2012 13:16:20 -0500

Hi Alexey

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.

> 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>
>
>    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>

> receiver of the lcfg attribute MUST ignore the values.
> .
>

Thanks

-- Flemming

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 11 Dec 2012 10:13:24 +0200

Hi,

I have not seen any answer to the email below (I may have missed it) in
which Flemming proposed some new text to address Alexey's review. What
is the status here?

Cheers,

Gonzalo

On 04/12/2012 8:16 PM, Flemming Andreasen wrote:
>       the value(s) of the keying material SHOULD be meaningless, and the

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 12 Dec 2012 19:13:38 +0000

On 04/12/2012 18:16, Flemming Andreasen wrote:
> Hi Alexey,
Hi Flemming,
>> 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).
>
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.
>> 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>
>           (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 receiver of the lcfg attribute
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"?
>> receiver of the lcfg attribute MUST ignore the values.
Best Regards,
Alexey

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 12 Dec 2012 17:08:21 -0500

On 12/12/12 2:13 PM, Alexey Melnikov wrote:
> problem. In particular media type syntax. But I am Ok with no change 
> in this area.
>>> similar to
>>           the attribute. Since the keying material will be visible 
>> but not actually used at this stage (since it's a latent configuration),
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