Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments

[Christer Holmberg <[e-mail]>]

Hi,

Below are my replies to Ben's technical comments.

----------------
Substantive Comments

> -1, first paragraph: RFC 5572-update is currently in IETF LC. Is there a reason not to reference it instead?

I assume you mean 4572-update :)

I agree that we should reference that spec instead, and I'll fix that.

----

> -4.1, last paragraph:
> I assume this paragraph refers to fmt values used with UDP/DTLS/SCTP or TCP/DTLS/SCTP, 
> not fmt values in general.

Correct. 

> It would help to be explicit about that.

The first sentence in section 4.1 does say:

   "This section defines the following new SDP Media Description (m-
   line) protocol identifiers (proto values) for describing an SCTP
   association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'."

> (Also, it seem like this paragraph belongs in section 4.3).

I could move and combine it with the 4th paragraph of section 4.3:

   "The m- line fmt value, identifying the application-layer protocol,
   MUST be registered by IANA. Section 15.3 defines the IANA registry 
   for the media format namespace."

----

> -4.5: The example is missing the sctp-port attribute.

I'll add it.

----

> -5.3: Why is the mux-category SPECIAL rather than CAUTION? IIUC, SPECIAL means you need to refer
> to the rules in the protocol definition. But the text here basically say that the rules are undefined.

I'm ok using CAUTION. I agree it might be more appropriate than SPECIAL.

----

> -6.1: What is meant by saying an "endpoint MUST assume that larger ... 
> will be rejected"? Can that be stated in terms of actual procedure (e.g. 
> "endpoint MUST NOT send...larger"?

I'd like Roman's input on this, in case he had some cases in mind where endpoint will have to send larger messages.

I guess we could say SHOULD NO send larger message, and explain that one cannot assume that larger message (if sent for whatever reason) will be accepted by the peer.

----

> -6.2, "Purpose" field: Please include the unit here, too.

I'll change to "maximum message size (indicated in bytes) that..."
                                 
----

> -9.1, 2nd paragraph: Don't the lower layers need to be established before the
> upper layers? Won't removal of the TCP connection or DTLS association break 
> an existing SCTP association?

Roman had lots of input on this, so I'll let him reply.

----

> -18.2: Seems like RFC0793 and RFC6544 should be normative references.

I'll fix that.

Regards,

Christer