Skip to main content

Requirements for Internet Media Guides (IMGs)
RFC 4473

Yes

(Jon Peterson)

No Objection

(Allison Mankin)
(David Kessens)
(Margaret Cullen)
(Russ Housley)
(Scott Hollenbeck)

Note: This ballot was opened for revision 08 and is now closed.

Jon Peterson Former IESG member
Yes
Yes ()

                            
Allison Mankin Former IESG member
No Objection
No Objection ()

                            
David Kessens Former IESG member
No Objection
No Objection ()

                            
Harald Alvestrand Former IESG member
No Objection
No Objection (2005-01-20)
Reviewed by Spencer Dawkins, Gen-ART

He has a number of comments (copied to document log), but none that I see as warranting blocking the document for that reason alone.
Margaret Cullen Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
No Objection
No Objection ()

                            
Scott Hollenbeck Former IESG member
No Objection
No Objection ()

                            
Ted Hardie Former IESG member
(was Discuss) No Objection
No Objection (2005-01-18)
I'm concerned that the potential roles of intermediaries are under-specified here.
In the introduction, the document says:

   Finally, with many potential senders and receivers, different types
   of networks, and presumably numerous service providers, IMG metadata
   may need to be combined, split, filtered, augmented, modified, etc.,
   on their way from the sender(s) to the receiver(s) to provide the
   ultimate user with a suitable selection of multimedia services
   according to her preferences, subscriptions, location, context (e.g.
   devices, access networks), etc.

The Security Considerations section does have some mention of 
the role of intermediaries, e.g.

   REQ AUT-5: It MUST be possible to separate or combine individually
   authenticated pieces of IMG metadata (e.g. in an IMG transceiver)

but the general mechanisms by which the receiver, sender, and intermediaries
interact does not seem to have generated sufficient requirements to ensure
that later protocol work will succeed.

I've had a short side discussion with Jon on this, and I agree that this could
be specified in a separate document, if that's the way the WG wants to tackle
things.