Requirements for Distributed Mobility Management
draft-ietf-dmm-requirements-17

[Ballot comment]
Thanks for working together on REQ6: Operation and Management considerations.
Next time, let's work on this while the document is still in the WG.

[Ballot discuss]
- My initial DISCUSS was: 'm always surprised that a requirements document doesn't contain any operations and management requirements.  Not logging, OAM, troubleshooting requirements, really? No OPS requirements to make management less complex or reduce the OPEX?
I'm after some guarantee that OPS is not an afterthought.

I see that you have introduced the REQ 8.
My DISCUSS is there to make you think from day one what your operations and management requirements are. Just one sentence "SHOULD be oam friendly" is like like "hey mister OPS AD, we have one sentence for you, now clear your DISCUSS please".
What are your DMM requirements in terms fault, configuration, accounting, performance, and OAM?
Let's pretend that Jouni, as an OPS Directorate, would review your proposed specifications work (in the next charter). He would take RFC 5706 appendix A and review the questions in here. I'm simply asking that you look at these questions, and that you write down your DMM requirements.


Discuss point 2. Cleared. Thanks

[Ballot comment]
I'm clearing the DISCUSS based on discussions with the authors.

In section 1, item 1, first paragraph:
        Evolved Packet Core (EPC) [TS.29303].  Yet these mechanisms were
        not pursued in the past owing to charging and billing which
        require solutions beyond the mobility protocol.  Consequently,
        assigning a gateway anchor node from a visited network in
        roaming scenario has until recently been done and are limited to
        voice services only.

This reads (to me) as if there's some intent to charge/bill for content delivery through WLAN offloading.  Is that correct?

Also, the last sentence just doesn't parse.  Can you explain in a slightly longer form what it is intended to mean?

Text of former DISCUSS:

Based on discussion with the IESG, I am updating this DISCUSS.

My concern about this document is that it's making a change to the way mobile IP is done that I think is a very good change, but I don't think it's going far enough.  I think that with some relatively small changes, this could be stating requirements for a mobile IP architecture that works well in the currently intended environment, but also allows for a permissionless mode of operation—that is, allows at least some more intelligent mobile devices to participate in the mobile architecture even when they connect to a network that is not operated by their mobile operator, and that has no formal agreement to interoperate with their mobile operator's mobility infrastructure.

This is important for two reasons.  First of all, it allows for greater utility for the mobile device when it is in a location where the mobile operator provides no service, or provides poorer service than is available on a local non-affiliated WLAN.  Second, it creates an opportunity for lock-in, where by offering better service on the affiliated network than is available on a non-affiliated network, the customer will be motivated to switch wireline providers, and possibly to set up their home network in a way that isn't in their overall best interests in order to accommodate the mobile provider's mobility infrastructure.

To address this DISCUSS, what I am asking for is a change to REQ5 as follows.
OLD:
          protocols.  Furthermore, a DMM solution SHOULD work across
          different networks, possibly operated as separate
          administrative domains, when allowed by the trust relationship
          between them.
NEW:
          protocols.  Furthermore, a DMM solution SHOULD work across
          different networks, possibly operated as separate
          administrative domains, when allowed by the trust relationship
          between them.

REQ5a:
          In cases where there is no trust relationship
          between administrative domains, it should still be possible
          for a node to authenticate to its provider's mobility
          infrastructure so that it can offer mobility service to
          applications that require it.

REQ5b:
          When roaming on networks for which there is no relationship
          between administrative domains, some services such as QoS
          may not be achievable using DMM signaling.  A DMM
          solution should specify a fallback mechanism for
          providing QoS when it is required (e.g. for emergency
          service) and the provider network is available, even
          when the non-affiliated WLAN is being used for offload.

REQ5c:
          A DMM solution may have some mechanism for negotiating
          QoS with a non-affiliated provider.

The last bit isn't really a requirement, but more of a "would be a good extension, probably doesn't belong in the base spec".  None of this is text I seriously think should go in the document as written—I'm just providing it to illustrate what it is that I am asking for.  How this DISCUSS gets resolved depends on how the IESG as a whole reacts to it.

BTW, although my expertise on mobile IP protocols is very shallow, the requirements I'm proposing here are not motivated purely by  my personal preferences as an end-user.  The new requirements I'm suggesting would allow mobile operators to extend their service offerings to handsets in environments where that currently isn't possible.  This capability is currently an open item in some discussions I've had with mobile operators, and a DMM solution that addressed it would be very helpful.

[Ballot comment]
I would like to see the applicability and deployment considerations clearly documented.
I am happy for this to be part of the rechartering rather than requiring it in this draft.

I understand that with work, the current deployment environment may be changing.

[Ballot discuss]
I am agreeing with Ted's DISCUSS at least to the extent that this document
should have an applicability assumptions section that clearly specifies the expected
environment and the assumptions that applies on to the solution and the requirements.

I can guess about the walled garden and single operator aspects, but those are guesses.
I certainly don't object to having good standards for interoperability even in walled garden
and single operator scenarios - but those architectural and applicability assumptions
will drive a different solution and should be captured in the requirements doc.

From Brian's email, it sounds like these are covered in the Proxy IPv6 Architecture, so
this can amount to a clear reference to those and a statement as to what changes there
are for these requirements (if any).

[Ballot discuss]
- I'm always surprised that a requirements document doesn't contain any operations and management requirements.  Not logging, OAM, troubleshooting requirements, really? No OPS requirements to make management less complex or reduce the OPEX?
I'm after some guarantee that OPS is not an afterthought.


- You make a distinction between:

  Mobility management may be partially or fully distributed
  [I-D.yokota-dmm-scenario].  In the former case only the data plane is
  distributed, implicitly assuming separation of data and control
  planes as described in [I-D.wakikawa-netext-pmip-cp-up-separation].
  Fully distributed mobility management implies that both the data
  plane and the control plane are distributed.

And I'm not sure what is the requirements are about: only partial or fully distributed?
When I look at REQ1, I'm not sure.

[Ballot discuss]
Based on discussion with the IESG, I am updating this DISCUSS.

My concern about this document is that it's making a change to the way mobile IP is done that I think is a very good change, but I don't think it's going far enough.  I think that with some relatively small changes, this could be stating requirements for a mobile IP architecture that works well in the currently intended environment, but also allows for a permissionless mode of operation—that is, allows at least some more intelligent mobile devices to participate in the mobile architecture even when they connect to a network that is not operated by their mobile operator, and that has no formal agreement to interoperate with their mobile operator's mobility infrastructure.

This is important for two reasons.  First of all, it allows for greater utility for the mobile device when it is in a location where the mobile operator provides no service, or provides poorer service than is available on a local non-affiliated WLAN.  Second, it creates an opportunity for lock-in, where by offering better service on the affiliated network than is available on a non-affiliated network, the customer will be motivated to switch wireline providers, and possibly to set up their home network in a way that isn't in their overall best interests in order to accommodate the mobile provider's mobility infrastructure.

To address this DISCUSS, what I am asking for is a change to REQ5 as follows.
OLD:
          protocols.  Furthermore, a DMM solution SHOULD work across
          different networks, possibly operated as separate
          administrative domains, when allowed by the trust relationship
          between them.
NEW:
          protocols.  Furthermore, a DMM solution SHOULD work across
          different networks, possibly operated as separate
          administrative domains, when allowed by the trust relationship
          between them.

REQ5a:
          In cases where there is no trust relationship
          between administrative domains, it should still be possible
          for a node to authenticate to its provider's mobility
          infrastructure so that it can offer mobility service to
          applications that require it.

REQ5b:
          When roaming on networks for which there is no relationship
          between administrative domains, some services such as QoS
          may not be achievable using DMM signaling.  A DMM
          solution should specify a fallback mechanism for
          providing QoS when it is required (e.g. for emergency
          service) and the provider network is available, even
          when the non-affiliated WLAN is being used for offload.

REQ5c:
          A DMM solution may have some mechanism for negotiating
          QoS with a non-affiliated provider.

The last bit isn't really a requirement, but more of a "would be a good extension, probably doesn't belong in the base spec".  None of this is text I seriously think should go in the document as written—I'm just providing it to illustrate what it is that I am asking for.  How this DISCUSS gets resolved depends on how the IESG as a whole reacts to it.

BTW, although my expertise on mobile IP protocols is very shallow, the requirements I'm proposing here are not motivated purely by  my personal preferences as an end-user.  The new requirements I'm suggesting would allow mobile operators to extend their service offerings to handsets in environments where that currently isn't possible.  This capability is currently an open item in some discussions I've had with mobile operators, and a DMM solution that addressed it would be very helpful.

[Ballot discuss]
Based on discussion with the IESG, I am updating this DISCUSS.

My concern about this document is that it's making a change to the way mobile IP is done that I think is a very good change, but I don't think it's going far enough.  I think that with some relatively small changes, this could be stating requirements for a mobile IP architecture that works well in the currently intended environment, but also allows for a permissionless mode of operation—that is, allows at least some more intelligent mobile devices to participate in the mobile architecture even when they connect to a network that is not operated by their mobile operator, and that has no formal agreement to interoperate with their mobile operator's mobility infrastructure.

This is important for two reasons.  First of all, it allows for greater utility for the mobile device when it is in a location where the mobile operator provides no service, or provides poorer service than is available on a local non-affiliated WLAN.  Second, it creates an opportunity for lock-in, where by offering better service on the affiliated network than is available on a non-affiliated network, the customer will be motivated to switch wireline providers, and possibly to set up their home network in a way that isn't in their overall best interests in order to accommodate the mobile provider's mobility infrastructure.

To address this DISCUSS, what I am asking for is a change to REQ5 as follows.
OLD:
          protocols.  Furthermore, a DMM solution SHOULD work across
          different networks, possibly operated as separate
          administrative domains, when allowed by the trust relationship
          between them.
NEW:
          protocols.  Furthermore, a DMM solution SHOULD work across
          different networks, possibly operated as separate
          administrative domains, when allowed by the trust relationship
          between them.

REQ5a:
          In cases where there is no trust relationship
          between administrative domains, it should still be possible
          for a node to authenticate to its provider's mobility infrastructure
          so that it can offer mobility service to applications that require it.

REQ5b:
          When roaming on networks for which there is no relationship
          between administrative domains, some services such as QoS
          may not be achievable using DMM signaling.  A DMM
          solution should specify a fallback mechanism for
          providing QoS when
          it is required (e.g. for emergency service) and the provider
          network is available, even if the
          non-affiliated WLAN is being used for offload.

REQ5c:
          A DMM solution may have some mechanism for negotiating
          QoS with a non-affiliated provider.

The last bit isn't really a requirement, but more of a "would be a good extension, probably doesn't belong in the base spec".  None of this is text I seriously think should go in the document as written—I'm just providing it to illustrate what it is that I am asking for.  How this DISCUSS gets resolved depends on how the IESG as a whole reacts to it.

BTW, although my expertise on mobile IP protocols is very shallow, the requirements I'm proposing here are not motivated purely by  my personal preferences as an end-user.  The new requirements I'm suggesting would allow mobile operators to extend their service offerings to handsets in environments where that currently isn't possible.  This capability is currently an open item in some discussions I've had with mobile operators, and a DMM solution that addressed it would be very helpful.

[Ballot discuss]
Based on discussion with the IESG, I am updating this DISCUSS.

My concern about this document is that it's making a change to the way mobile IP is done that I think is a very good change, but I don't think it's going far enough.  I think that with some relatively small changes, this could be stating requirements for a mobile IP architecture that works well in the currently intended environment, but also allows for a permissionless mode of operation—that is, allows at least some more intelligent mobile devices to participate in the mobile architecture even when they connect to a network that is not operated by their mobile operator, and that has no formal agreement to interoperate with their mobile operator's mobility infrastructure.

This is important for two reasons.  First of all, it allows for greater utility for the mobile device when it is in a location where the mobile operator provides no service, or provides poorer service than is available on a local non-affiliated WLAN.  Second, it creates an opportunity for lock-in, where by offering better service on the affiliated network than is available on a non-affiliated network, the customer will be motivated to switch wireline providers, and possibly to set up their home network in a way that isn't in their overall best interests in order to accommodate the mobile provider's mobility infrastructure.

To address this DISCUSS, what I am asking for is a change to REQ5 as follows.
OLD:
          protocols.  Furthermore, a DMM solution SHOULD work across
          different networks, possibly operated as separate
          administrative domains, when allowed by the trust relationship
          between them.
NEW:
          protocols.  Furthermore, a DMM solution SHOULD work across
          different networks, possibly operated as separate
          administrative domains, when allowed by the trust relationship
          between them.

REQ5a:
          In cases where there is no trust relationship
          between administrative domains, it should still be possible
          for a node to authenticate to its provider's mobility infrastructure
          so that it can offer mobility service to applications that require it.

REQ5b:
          When roaming on networks for which there is no relationship
          between administrative domains, some services such as QoS
          may not be achievable using DMM signaling.  A DMM solution
          should specify a fallback mechanism for providing QoS when
          it is required (e.g. for emergency service) and the provider
          network is available, even if the
          non-affiliated WLAN is being used for offload.

REQ5c:
          A DMM solution may have some mechanism for negotiating
          QoS with a non-affiliated provider.

The last bit isn't really a requirement, but more of a "would be a good extension, probably doesn't belong in the base spec".  None of this is text I seriously think should go in the document as written—I'm just providing it to illustrate what it is that I am asking for.  How this DISCUSS gets resolved depends on how the IESG as a whole reacts to it.

[Ballot comment]
In section 1, item 1, first paragraph:
        Evolved Packet Core (EPC) [TS.29303].  Yet these mechanisms were
        not pursued in the past owing to charging and billing which
        require solutions beyond the mobility protocol.  Consequently,
        assigning a gateway anchor node from a visited network in
        roaming scenario has until recently been done and are limited to
        voice services only.

This reads (to me) as if there's some intent to charge/bill for content delivery through WLAN offloading.  Is that correct?

Also, the last sentence just doesn't parse.  Can you explain in a slightly longer form what it is intended to mean?

[Ballot discuss]
I am agreeing with Ted's DISCUSS at least to the extent that this document
should have an applicability assumptions section that clearly specifies the expected
environment and the assumptions that applies on to the solution and the requirements.

I can guess about the walled garden and single operator aspects, but those are guesses.
I certainly don't object to having good standards for interoperability even in walled garden
and single operator scenarios - but those architectural and applicability assumptions
will drive a different solution and should be captured in the requirements doc.

[Ballot comment]
(1)  Mobile users are, more than ever, consuming Internet content
        including that of local Content Delivery Networks (CDNs) which
        had not taken mobility service into account before. 

It's a bit more accurate to characterize this as the CDN's being unable to take mobility services into account due to the design of mobile networks.

It's fair to say  that I don't think I'm  going to like what we do next here. but I can live with this document.

[Ballot comment]

I have two suggestions:

- REQ6: Why MUST existing security protocols be used to
mitigate risks introduced because of a DMM solution? That
seems wrong. I think you want to say that you prefer
existing security protocols and strongly prefer existing
security mechanisms.

- REQ6: I would suggest that adding a sentence to REQ6
along these lines might be appropriate: "A DMM solution
SHOULD improve security and privacy for the user and the
network where possible." Merely saying "do not be worse"
seems like a fairly lame requirement given that the threat
landscape is constantly evovling and this is not aiming
for very short term deployments only. Make sense?

[Ballot comment]
In section 1, item 1, first paragraph:
        Evolved Packet Core (EPC) [TS.29303].  Yet these mechanisms were
        not pursued in the past owing to charging and billing which
        require solutions beyond the mobility protocol.  Consequently,
        assigning a gateway anchor node from a visited network in
        roaming scenario has until recently been done and are limited to
        voice services only.

This reads (to me) as if there's some intent to charge/bill for content delivery through WLAN offloading.  Is that correct?

Also, the last sentence just doesn't parse.  Can you explain in a slightly longer form what it is intended to mean?

As a general observation about this requirements document, it appears to presuppose that DMM will only work in circumstances where there is either a single administrative domain, or tight integration between multiple administrative domains.  Is that really a necessary requirement for a DMM architecture?

[Ballot discuss]
Question for the IESG: given that this is a requirements document that will presumably motivate further development work, is it appropriate that it is not an IETF consensus document?

[Ballot comment]
In section 1, item 1, first paragraph:
        Evolved Packet Core (EPC) [TS.29303].  Yet these mechanisms were
        not pursued in the past owing to charging and billing which
        require solutions beyond the mobility protocol.  Consequently,
        assigning a gateway anchor node from a visited network in
        roaming scenario has until recently been done and are limited to
        voice services only.

This reads (to me) as if there's some intent to charge/bill for content delivery through WLAN offloading.  Is that correct?

Also, the last sentence just doesn't parse.  Can you explain in a slightly longer form what it is intended to mean?

As a general observation about this requirements document, it appears to presuppose that DMM will only work in circumstances where there is either a single administrative domain, or tight integration between multiple configuration domains.  Is that really a necessary requirement for a DMM architecture?

[Ballot comment]
Good stuff. Couple of nits:

There are a few places where the phrase "the DMM solution" is used, but I'm under the impression that multiple solutions exist and may be standardized, so it would probably be better to talk about "a solution" or "solutions."

Section 1:

"Yet these mechanisms were not pursued in the past owing to charging and billing which
        require solutions beyond the mobility protocol.  Consequently,
        assigning a gateway anchor node from a visited network in
        roaming scenario has until recently been done and are limited to
        voice services only."

I'm having trouble parsing this. Is it supposed to say "assigning a gateway anchor node from a visited network in a roaming scenario has until recently not been done"? Is the cited "roaming scenario" the same as the off-load scenario described earlier in the paragraph?

[Ballot discuss]
I have no objection to this fine document, and just have a small thing I'd like to discuss:
In Section 2.1 you list three RFCs (3753, 5213, and 6275) that define terminology that's required to understand this document.  I think that makes those RFCs normative references.  Please explain why they're informative.

[Ballot comment]
I have no objection to the publication of this document as an
Informational RFC.

---

I believe you could useful clarify "levels of routing hierarchy" through
an addition to Section 2.1

---

The shepherd write-up is silent on question 11 which is a shame because
this revision has nits.

---

In Section 5, it would be nice if the paragraphs "This requirement
addresses..." were indented with the requirements they belong to.
currently it looks like they are header text for the next requirement
rather than footer text for the previous requirement.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dmm-requirements-13, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if authors prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Requirements for Distributed Mobility Management) to Informational RFC


The IESG has received a request from the Distributed Mobility Management
WG (dmm) to consider the following document:
- 'Requirements for Distributed Mobility Management'
  as Informational RFC

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 2014-02-17. 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


  This document defines the requirements for Distributed Mobility
  Management (DMM) at the network layer.  The hierarchical structure in
  traditional wireless networks has led primarily to centralized
  deployment models.  As some wireless networks are evolving away from
  the hierarchical structure, a distributed model for mobility
  management can be useful to them.





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

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


No IPR declarations have been submitted directly on this I-D.

> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)? Why is
> this the proper type of RFC? Is this type of RFC indicated in the title
> page header?

Requesting Informational RFC as this is a requirements document.

> (2) 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:
>
> Relevant content can frequently be found in the abstract and/or
> introduction of the document. If not, this may be an indication that
> there are deficiencies in the abstract or introduction.

This document defines the requirements for Distributed Mobility Management
(DMM).  The hierarchical structure in traditional wireless networks
has led primarily to centralized deployment models.  As some wireless
networks are evolving away from the hierarchical structure, a distributed
model for mobility management can be useful to them.

> Working Group Summary:
>
> Was there anything in WG process that is worth noting? For example, was
> there controversy about particular points or were there decisions where
> the consensus was particularly rough?

There was disagreement from one participant on whether some of the
requirements were stated clearly enough to make a convincing case for a
new distributed mobility management model.  However, there was general
consensus in the WG that the text adequately describes the shortcomings
of current mobility management algorithms in terms of resource consumption
when used in multicast, CDN, and peer-to-peer style applications.

> Document Quality:
>
> Are there existing implementations of the protocol? Have a significant
> number of vendors indicated their plan to implement the specification?
> Are there any reviewers that merit special mention as having done a
> thorough review, e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues? If there was a
> MIB Doctor, Media Type or other expert review, what was its course
> (briefly)? In the case of a Media Type review, on what date was the
> request posted?

This is a requirements document so there is currently no implementation.

> Personnel:
>
> Who is the Document Shepherd? Who is the Responsible Area Director?

Peter McCann is the document shepherd.  Brian Haberman is the
responsible AD.

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd. If this version of the document is not ready for
> publication, please explain why the document is being forwarded to the
> IESG.

The document shepherd reviewed the document against the latest round of
comments from the WG, and believes the document is ready to be forwarded
to the IESG.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that took
> place.

The document describes requirements for mobility management and was
adequately reviewed by the community of participants in mobility-related
IETF WGs.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has 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.

The shepherd has no concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that they are unaware of any IPR related
to this draft.

> (8) Has an IPR disclosure been filed that references this document? If
> so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

No IPR disclosures have been filed.

> (9) 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?

The WG as a whole is in agreement that the document is ready for
publication.

> (10) 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 publicly available.)

No appeal has been threatened, and the disagreements noted above were
explicitly noted as non-blocking by the maker of the comments.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.


> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

No such formal reviews are needed.

> (13) Have all references within this document been identified as either
> normative or informative?

Yes.

> (14) 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 plan for their completion?

No unfinished normative references are used.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

No downward normative references are used.

> (16) Will publication of this document change the status of any existing
> RFCs? Are those RFCs listed on the title page header, listed in the
> abstract, and discussed in the introduction? If the RFCs are not listed
> in the Abstract and Introduction, explain why, and point to the part of
> the document where the relationship of this document to the other RFCs
> is discussed. If this information is not in the document, explain why
> the WG considers it unnecessary.

Publication of this document will not affect the status of any other
RFC.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

No IANA considerations are given because this is a requirements
document.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find useful
> in selecting the IANA Experts for these new registries.

No new IANA registries are created by this document.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

No formal notation is used in the document.

Folks,

There was no opposition to the document, thus we can
conclude it is done from the WG point of view.

Pete McCann will be the document shepherd and guide
the document through the rest of the process.

- Jouni & Dapeng



On Nov 25, 2013, at 11:18 AM, Jouni Korhonen  wrote:

> Folks,
>
> This mail starts a quick one week WGLC for
> draft-ietf-dmm-requirements-11 to verify the
> changes done since the last WGLC. After the
> WGLC we are about to move the draft out of the
> working group.
>
> The WGLC ends 2-Dec-2013.
>
> If you have something comment, send it into the
> mailing list and possibly add into the issue
> tracker. We take silence as an acceptance for the
> draft content.
>
> - Jouni & Dapeng

A new quick one week WGLC just to verify the changes done to the previous version. The WGLC ends 2-Dec-2013. No comments means everything is ok and the document can move forward.

On Jul 24, 2013, at 1:02 AM, Jouni Korhonen  wrote:



Folks,

The requirements draft still seems to have 11 open tickets:
http://tools.ietf.org/wg/dmm/trac/query?status=new&status=assigned&status=reopened&component=requirements

Those who recorded the issues should check whether -05 addresses them.

- Jouni

Folks,

This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03.
The issues, even editorials, must be recorded into the Issue Tracker,
otherwise they are likely to be neglected. We require minimum three
reviews (that are more than one liners). The more the better, though.

The WGLC ends on Wednesday 24rd April.

- Jouni & Julien