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

[Ballot discuss]
To be honest, I'm not sure if these are easy or hard questions,
but that should become clear quickly as we discuss 'em;-)

(1) cleared

(2) cleared

(3) cleared

(4) 5.1.5.21 - where can I find a list of keying-mechanisms
that could be supported? If I cannot, then how do I get
interop with this element? (Same for 5.2.5.1.2.8 and
5.2.5.1.3.8)

[Ballot comment]
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. ( 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

[Ballot discuss]
To be honest, I'm not sure if these are easy or hard questions,
but that should become clear quickly as we discuss 'em;-)

(1) There are lots of places where zero or more child
elements are allowed, but no semantics is described for that
syntactically valid choice (e.g. 5.1.5.2). I don't get why
this is ok - can you explain?  If it is, be good to say why
in the spec. If its not ok, then I guess that needs fixing.

(2) cleared

(3) cleared

(4) 5.1.5.21 - where can I find a list of keying-mechanisms
that could be supported? If I cannot, then how do I get
interop with this element? (Same for 5.2.5.1.2.8 and
5.2.5.1.3.8)

[Ballot comment]

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

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]

  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.

[Ballot comment]
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.

[Ballot comment]
Overlapping Stephen a bit:

5.1.2:

  The  element has the following child elements, only one
  of which is allowed to occur in a request.
 
First of all, referring to an  "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  message; that sounds like it should say instead:

  The  element has the following child elements, and there
  MUST NOT be more than one such child element in any
  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  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.

[Ballot comment]
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.

[Ballot discuss]

To be honest, I'm not sure if these are easy or hard questions,
but that should become clear quickly as we discuss 'em;-)

(1) There are lots of places where zero or more child
elements are allowed, but no semantics is described for that
syntactically valid choice (e.g. 5.1.5.2). I don't get why
this is ok - can you explain?  If it is, be good to say why
in the spec. If its not ok, then I guess that needs fixing.

(2) 5.1.5.4 - can the conferenceid attribute value be
sensitive? i.e. is confidentiality likely to be required for
this in transit, or obfuscation or masking of the value so
the MRB doesn't get it? Or is that just not a problem?

(3) Which part wins (i.e. is normative) if there are
differences, the schema or the descriptive text in earlier
sections? I noticed this because there is a fair amount of
duplication (thus maybe making such errors more likely) and
e.g. 5.1.5.20 doesn't state the name of the single attribute.

(4) 5.1.5.21 - where can I find a list of keying-mechanisms
that could be supported? If I cannot, then how do I get
interop with this element? (Same for 5.2.5.1.2.8 and
5.2.5.1.3.8)

[Ballot comment]


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

[Ballot comment]
Section 5.1.5.15., paragraph 4:

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

IANA has reviewed draft-ietf-mediactrl-mrb-16 and has the following
comments:

IANA has questions about some of the IANA actions requested in this document.

Upon approval of this document, IANA understands that there are four IANA
actions which it must complete.

First, in the Control Packages subregistry of the Media Control Channel
Framework Parameters registry located at:

http://www.iana.org/assignments/media-control-channel/media-control-channel.xml

a new Control Package is to be registered as follows:

Name: mrb-publish/1.0
Reference: [ RFC-to-be ]

Second, two new media types are to be added to the applications media type
registry located at:

http://www.iana.org/assignments/media-types/application/index.html

The media types to be added are:

mrb-publish+xml
mrb-consumer+xml

Currently the application media type library is maintained through expert review
as defined in RFC 5226.

IANA Question -> has the document been reviewed by the Media Type expert?

Third, two new XML namespaces are to be registered in the ns registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

the registrations are as follows:

ID: mrb-publish
URI: urn:ietf:params:xml:ns:mrb-publish
Registration template: [ provided in Section 10 of RFC-to-be ]
Reference: [ RFC-to-be ]

ID: mrb-consumer
URI: urn:ietf:params:xml:ns:mrb-consumer
Registration template: [ provided in Section 11 of RFC-to-be ]
Reference: [ RFC-to-be ]

Fourth, two new XML schemas are to be registered in the schema registry
located at:

http://www.iana.org/assignments/xml-registry/schema.html

the registrations are as follows:

ID: mrb-publish
URI: urn:ietf:params:xml:schema:mrb-publish
Filename: mrb-publish [ schema provided in Section 10 of RFC-to-be ]
Reference: [ RFC-to-be ]

ID: mrb-consumer
URI: urn:ietf:params:xml:schema:mrb-consumer
Filename: mrb-consumer [ schema provided in Section 11 of RFC-to-be ]
Reference: [ RFC-to-be ]

IANA understands that these four actions are the only ones required
to be completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Media Resource Brokering) to Proposed Standard


The IESG has received a request from the Media Server Control WG
(mediactrl) to consider the following document:
- 'Media Resource Brokering'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-11-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The MediaCtrl work group in the IETF has proposed an architecture for
  controlling media services.  The Session Initiation Protocol (SIP) is
  used as the signalling protocol which provides many inherent
  capabilities for message routing.  In addition to such signalling
  properties, a need exists for intelligent, application level media
  service selection based on non-static signalling properties.  This is
  especially true when considered in conjunction with deployment
  architectures that include 1:M and M:N combinations of Application
  Servers and Media Servers.  This document introduces a Media Resource
  Broker (MRB) entity which manages the availability of Media Servers
  and the media resource demands of Application Servers.  The document
  includes potential deployment options for an MRB and appropriate
  interfaces to Application Servers and Media Servers.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1876/

IANA has reviewed draft-ietf-mediactrl-mrb-15 and has the following comments:

IANA has questions about some of the IANA actions requested in this document.

Upon approval of this document, IANA understands that there are four IANA
actions which it must complete.

First, in the Control Packages subregistry of the Media Control Channel
Framework Parameters registry located at:

http://www.iana.org/assignments/media-control-channel/media-control-channel.xml

a new Control Package is to be registered as follows:

Name: mrb-publish/1.0
Reference: [ RFC-to-be ]

Second, two new media types are to be added to the applications media type
registry located at:

http://www.iana.org/assignments/media-types/application/index.html

The media types to be added are:

mrb-publish+xml
mrb-consumer+xml

Currently the application media type library is maintained through expert review
as defined in RFC 5226.

IANA Question -> has the document been reviewed by the Media Type expert?

Third, two new XML namespaces are to be registered in the ns registry
located at:

http://www.iana.org/assignments/xml-registry/ns.html

the registrations are as follows:

ID: mrb-publish
URI: urn:ietf:params:xml:ns:mrb-publish
Registration template: [ provided in Section 10 of RFC-to-be ]
Reference: [ RFC-to-be ]

ID: mrb-consumer
URI: urn:ietf:params:xml:ns:mrb-consumer
Registration template: [ provided in Section 11 of RFC-to-be ]
Reference: [ RFC-to-be ]

Fourth, two new XML schemas are to be registered in the schema registry
located at:

http://www.iana.org/assignments/xml-registry/schema.html

the registrations are as follows:

ID: mrb-publish
URI: urn:ietf:params:xml:schema:mrb-publish
Filename: mrb-publish [ schema provided in Section 10 of RFC-to-be ]
Reference: [ RFC-to-be ]

ID: mrb-consumer
URI: urn:ietf:params:xml:schema:mrb-consumer
Filename: mrb-consumer [ schema provided in Section 11 of RFC-to-be ]
Reference: [ RFC-to-be ]

IANA understands that these four actions are the only ones required
to be completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Media Resource Brokering) to Proposed Standard


The IESG has received a request from the Media Server Control WG
(mediactrl) to consider the following document:
- 'Media Resource Brokering'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-10-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The MediaCtrl work group in the IETF has proposed an architecture for
  controlling media services.  The Session Initiation Protocol (SIP) is
  used as the signalling protocol which provides many inherent
  capabilities for message routing.  In addition to such signalling
  properties, a need exists for intelligent, application level media
  service selection based on non-static signalling properties.  This is
  especially true when considered in conjunction with deployment
  architectures that include 1:M and M:N combinations of Application
  Servers and Media Servers.  This document introduces a Media Resource
  Broker (MRB) entity which manages the availability of Media Servers
  and the media resource demands of Application Servers.  The document
  includes potential deployment options for an MRB and appropriate
  interfaces to Application Servers and Media Servers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1876/

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The document shepherd is Dale Worley (a co-chair of Mediactrl).

In my opinion, the revision -12 is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

I believe the document has had adequate review.  People in the WG and
representatives of major application server and media server vendors
have contributed to and reviewed this document in meetings, mailing
lists and extra MediaCtrl sessions.  At least one vendor has built an
MRB to this specification.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

I have no such concerns.  The only plausible concern is that the
protocol seems to be overly complex, in that it allows several
different modes of operation for broadly similar actions.  But the
people involved in the draft are involved in practical deployments,
and I am sure that they have found the various alternatives in the
protocol are necessary in various practical situations.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

I have no such concerns.

Specifically regarding IPR:

AT&T has filed 3 IPR disclosures regarding the predecessor draft,
draft-boulton-mediactrl-mrb: ID # 897, ID # 898, and ID # 899.  AT&T
is listed as offering RAND licensing terms.

The IPR disclosures were submitted in 2007.  The chairs solicited
feedback from the WG twice, in 2007 and 2008.  There seems to have
been no response to the solilcitation and no further discussion of the
IPR issues on any IETF mailing list, suggesting that no controversy
ensued.  I would expect that any implementors who worried that the IPR
would be burdensome would have spoken up.

Neither of the chairs at the time (Eric Burger and Spencer Dawkins),
nor two of the three authors (Chris Boulton and Lorenzo Miniero) work
for AT&T, so there seems to be no reason to suspect undue influence of
AT&T to promote its commercial interests.  (The third author, Gary
Munson, does work for AT&T.)

The WGLC of 7 Feb 2012 specifically mentioned the IPR disclosures, to
provide a last opportunity for implementors to express any concerns
over the IPR situation.  No objections were raised regarding IPR.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

A WGLC was given on the -02 version on 15 Dec 2009.  It received no
responses.  A final WGLC on the -12 version was given on 7 Feb 2012.
It received no responses either.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

None that I can find any record of.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

"Registration of application/mrb-publish+xml and
application/mrb-consumer+xml" was sent to ietf-types on 19 Jan 2012.
Two responses were received from one person.  The comments were minor
editorial matters which I believe do not require change to the draft.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

Yes -- the nits tool (http://tools.ietf.org/tools/idnits/) is happy
with the draft.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

Yes.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Yes.  One author (Lorenzo Miniero) checked the schemas using Eclipse
and XML Spy, and validated the examples using a JAXB-based tool.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

Technical Summary

    The MediaCtrl work group in the IETF has proposed an architecture
    for controlling media services.  The Session Initiation Protocol
    (SIP) is used as the signalling protocol which provides many
    inherent capabilities for message routing.  A need exists for
    intelligent, application level media service selection based on
    non-static signalling properties, especially in deployment
    architectures that include 1:M and M:N combinations of Application
    Servers and Media Servers.  This document introduces a Media
    Resource Broker (MRB) entity which manages the availability of
    Media Servers and the media resource demands of Application
    Servers.  The document includes potential deployment options for an
    MRB and appropriate interfaces to Application Servers and Media
    Servers.

Working Group Summary

    The working group consensus on this document is solid.  Two
    WGLCs were held, one after the initial consensus on the
    document, and one after extensive review and implemention
    experience dictated a number of small improvements to the
    protocol and its description.

Document Quality

    The protocol described in this document has been implemented
    by several major vendors.  The description has also been
    carefully reviewed by someone not involved in its writing or
    implementation.

Personnel

    Dale Worley is the document's shepherd.
    Robert Sparks is the responsible AD.