A Framework for the Usage of Internet Media Guides (IMGs)
draft-ietf-mmusic-img-framework-09

[Ballot comment]
I still believe that addressing the issue below would be useful, but I have moved to abstain
in order that something might get published.  Here's the original DISCUSS text:

In 5.2.2, the document says:

  We anticipate that the IMG QUERY-RESOLVE
  operation will be a trivial usage of HTTP, although other transport
  protocol options may be beneficial to consider too.


This seems contrary to what is said in 5.1.1, where the analysis
notes that ANNOUNCE and VERIFY won't work in an HTTP-only
environment, and so HTTP is not sufficient for a unicast deployment.
If the IMG system is going to use multiple protocols (e.g. HTTP for
unicast Query-Resolve, SIP Notify for announce), then there will
be a reasonable amount of complexity in determining what to do when the
different protocols give answers.  I'm also surprised, given that
Henning is one of the authors, that the document would believe
"layered onto HTTP" meant simple; I'd have thought XCAP would
have beaten that notion out of him.

From: Spencer Dawkins
Date: 18 januari 2005


I reviewed this specification for Harald as a General Area Review Team
member.

This specification is almost ready for publication as an
Informational RFC.

I found Figure 1 to be very helpful - if it could be
introduced sooner, that would be even better.

The discussion in 4.2
ignores most of the "reliability" requirements in the companion
draft - is "announce" reliable? it would be best to come out and say
"yes" or "no".

The existing standards in section 5.1 need specific
references for each protocol.

SAP gets more words of description than
HTTP and SIP put together, and most of these words are explaining why
SAP isn't a good fit for the framework. Could this be shortened (to
"SAP isn't appropriate for these reasons")?

There are a few "be use to"s that should be "be used to".

Does the WG have a view on whether
ALC is likely to be insufficient or not, and why (in 5.2.1)?

In the
security considerations section, "IMG Authenticity" is included, but
this is "origin authentication", not "sender authentication".

In general, both drafts sidestep the description of an IMG transceiver.
This IS defined in the terms, but there's very little text that
describes them.

[Ballot discuss]
In 5.2.2, the document says:

  We anticipate that the IMG QUERY-RESOLVE
  operation will be a trivial usage of HTTP, although other transport
  protocol options may be beneficial to consider too.


This seems contrary to what is said in 5.1.1, where the analysis
notes that ANNOUNCE and VERIFY won't work in an HTTP-only
environment, and so HTTP is not sufficient for a unicast deployment.
If the IMG system is going to use multiple protocols (e.g. HTTP for
unicast Query-Resolve, SIP Notify for announce), then there will
be a reasonable amount of complexity in determining what to do when the
different protocols give answers.  I'm also surprised, given that
Henning is one of the authors, that the document would believe
"layered onto HTTP" meant simple; I'd have thought XCAP would
have beaten that notion out of him.