Media Resource Brokering
draft-ietf-mediactrl-mrb-19

I have reviewed this document for its impact on the routing system and have no objection to its publication.

I would caution all working in this area to be sensitive to the re-invention of wheels. Consider that "Media Server routing decisions" are routing decisions. Although they are relatively simple today, it is inevitable that they will grow more complex over time. Do not make the mistake of assuming that the diameter of your networks will always remain small and that routing can therefore be left as a simplistic process. Ensure that your architectures are forwards-compatible with future routing schemes.

Similarly, be aware that the resource brokering at this "network layer" is funcitonally similar to the resource brokering considered at other layers (TSV, RTG) and try to share your ideas as well as learn from others' work.

Section 5.1.5.15., paragraph 4:

>    <file-transfer-mode>:   has two attributes, 'name' and 'package'.
>       The 'name' attribute provides the scheme name of the protocol that
>       can be used for file transfer (e.g., "HTTP", "RTSP", etc.): the

  I do not know how RTSP is used for file transfer. The reference to RTSP is odd in this place.

Overlapping Stephen a bit:

5.1.2:

   The <mrbpublish> element has the following child elements, only one
   of which is allowed to occur in a request.
   
First of all, referring to an <mrbpublish> "request" is confusing. Don't you instead mean "message"? Also, (and my IESG colleagues will surely drop dead of heart attacks to hear me say it), the word "allowed" sounds like it would be an interoperability problem if someone attempted to put multiple children in an <mrbpublish> message; that sounds like it should say instead:

   The <mrbpublish> element has the following child elements, and there
   MUST NOT be more than one such child element in any <mrbpublish>
   message:
   
Did I get that right? (I wasn't clear on whether you could only have one child at all, or if you were allowed multiple occurrences of one *kind* of child.)

5.1.3.1 (as well as other uses of seqnumber):

      The first subscription MUST have 1 as
      'seqnumber', and following subscriptions MUST increment by 1 the
      previous 'seqnumber' value.

Really? Would any non-zero starting value suffice? Could it simply be any larger seqnumber rather than incrementing by 1? I'm basically wondering if the MUSTs are really all that MUSTy.

5.1.5.20:

   The <media-server-address> element has a single attribute.
   
OK, I give up: What is it? (OK, I know, it's the URI, but that is written oddly.)

13 (for example, 13.1):

      Person and email address to contact for further information:   IETF,
      MEDIACTRL working group, (mediactrl@ietf.org), Chris Boulton
      (chris@ns-technologies.com).

For a registration from an IETF RFC, is a person and email address really required? Seems like the potential for this to become out of date (WG is shut down, Chris moves on, etc), and it seems like "IETF" would suffice.

A more precise definition of exactly what this document
is about would be helpful - at least, it would have been
helpful to someone like me who is relatively
unfamiliar with 

For example, in the Abstract: "This document introduces
a Media Resource Broker (MRB) entity."  Does the
document give a description of an MRB, specify on-the-wire
protocols that an MRB would use, define the capabilities
and behavior of an MRB, ???

Is the intention that I could build an MRB based on this
document?

  I was expecting a reference to an IANA registry of keying-mechanisms
  in Section 5.1.5.21.  Without this reference, it is unclear to me
  how the keying material needed for encryption is managed.  Further,
  when encryption is supported, it would be very useful for one
  keying-mechanism to be mandatory.

1) subscription says can seer or more of the following child elements and then it says they're all MAY so can subscription be empty or must at least one of the child elements be present?  If none of the child elements are present should subscription just be omitted?

Actually this is true for a bunch of things.

2) Support Stephen's discuss on #4.

general - Using fewer words in a spec is better than more;
this draft doesn't do that. Not worth fixing now since it'd
be a huge job, but this could be a lot shorter and it'd IMO
have been clearer had that been the case.

abstract, intro: these are a bit opaque and assume the reader
knows what problem is being solved. You could usefully
clarify that.

5.1.2 - says that mrbpublish has zero or more of...version,
which MUST be present? And what would having two versions
look like or mean in an XML document? I think in this case
the additional words are getting in the way of clarity.

5.1.3 - so an empty mrbrequest is valid it seems, I hope you
tell me what that means somewhere:-)

5.1.3.1 - why MUST seqnumber start at 1? And does "start"
mean from 1st boot or every reboot? What happens if an
implementation's internal counter wraps around or is that not
allowed somehow? That's often IMO a bad plan as it allows for
guessing message field values which can open up
vulnerabilities. No idea if that applies here but generally
its better to start random IMO. (<seq> in 5.2.3 is handled
this way.)

5.1.3.1 - seqnumber description refers to session id but
sessions have not been described so far.  (Two comments above
also apply to 5.1.5)

5.1.4 - last para - this is confusing, you say the media
server MAY include this if requested values are
uncacceptable. That sounds like it ought really be a MUST or
else the condition ("unacceptable values") should be an
example.

5.1.5.14 - I have no idea why country codes are relevant
here, but I guess its some convention that's known to RAI
folks. Might be worth explaining as it was surprising to this
reader.

5.1.5.15 - What is "HTTS"? Are you missing a P?

5.2.2.1 last para - what "lease" do you mean here? Do you at
least need a forward ref to 5.2.3?

5.2.5.1.1.1 - too many levels of TOC IMO, could be seen as a
sign that there's something wrong here with the writing. 

5.2.5.1.1 - be good to expand IVR on first use

I have reviewed this document for impact on the routing system and as far as I can tell there is no impact. I therefore have no objection to its publication.