Re: AD Evaluation: draft-ietf-dmm-requirements

Regarding the following:
6. I would like to avoid issues further along the publication chain, so I would like the editors to look at how the contributing authors are identified in the draft.  A good approach is described in the RFC Style Guide (https://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can be problematic.
------------------
I have now read the guidelines that the list of authors refer to those on the front page only. This draft had benefited from very valuable inputs from many people, so that I had in the past tried to give the deserved recognition to name more co-authors by listing their names inside. I managed to get around with the ietf template so that I thought it was possible. Yet I now found that it is not in compliance with the rfc guidelines. The relevant sections of the guidelines are pasted at the end. 

I apologize for not having read these guidelines before. In the future revision, other than the authors in the front page, I can only acknowledge the valuable inputs from all the rest as contributors together with contact information, and I am sorry for having caused the misunderstanding and especially if it hurts anyone's feeling now.

As the work of the requirements draft is drawing close to completion now, I thank everyone again for the very helpful and useful work. 

H Anthony Chan

----------------

Authors vs. Contributors 

Questions are still arising about the editorial policies on RFC authorship, and the contents of the first page, of the Contributors section, and of the Authors' Address section. We will attempt to clarify. 

1. When the RFC Editor refers to "authors", we mean exactly the set of names listed on the first page of an RFC. These people are considered to be equally responsible for the contents of the document, and all will be asked to read and approve the RFC before publication. 

2. When the RFC Editor refers to "contributors", we mean people, other than the authors, who also contributed significantly to the RFC. They should be listed in a Contributors section of the body of the document. 

3. The last section of the document has traditionally been a section listing contact information for authors. The intent of this section is to tell readers how to get in touch with those people responsible for the document, to seek clarification, make comments, etc. This section should include contact information for all authors. This section has been titled "Author's Address" (or "Authors' Addresses"). 

4. The issue has arisen: can/should the Contributors section include contact information? The answer is yes, it may include contact information at the authors' discretion. 

19 August 2003. Updated 18 October 2006. Updated 14 June 2011.

-----Original Message-----
From: dmm [mailto:[email protected]] On Behalf Of Brian Haberman
Sent: Friday, January 24, 2014 11:30 AM
To: [email protected]; [email protected]; Peter McCann
Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements

All,
     I have performed my AD review, as a part of the publication process, of draft-ietf-dmm-requirements.  The following issues should be addressed prior to moving this draft to IETF Last Call.  Please let me know if you have any questions on these points.

1. I would suggest making sure that the Abstract and Introduction explicitly state that these requirements for for network (L3)-layer mobility management.

2. Introduction:

- The EPC acronym needs to be expanded.
- Do not reference the DMM charter within the document.
- expand HA and LMA since you are using them before the Terminology section.

3. Section 3:

- It would be nice to ensure that all acronyms used in the figures are expanded somewhere prior to the figures.

- I am curious as to why there is not any mention in this section about route optimization within the mobility protocols.  This mention should describe why current route optimization is host-based in order to lead into PS1.

4. Section 4:

- To be abundantly clear, I would re-word the start of PS3 to be "Lack of scalability".

- I am not sure that it benefits the document to label PS6 and PS7 as related.  Those issues are problematic on their own.  If you remove the "(related problem)" label from them, make sure that REQ2 is updated to remove mention of "related problem".

- Should PS7 mention mobility solutions that operated at other layers of the protocol stack?

5. Section 5:

- Why does this section have sub-section numbers AND REQ numbers?

- I am not sure I understand what REQ1 is saying when it talks about combining mobility anchors with CDNs.  It *sounds* like mobility management needs to be maintained by CDN providers.

- I am a little confused by REQ2.  It says that a DMM solution should be transparent to the applications.  However, the motivation talks about identifying applications that do (or do not) need mobility support from the network layer.  That doesn't sound transparent to me.  Am I reading this incorrectly?

- I am wondering if the SHOULD in REQ4 ought to be a MUST.  Why would anyone work on a new protocol without first determining the feasibility of the existing ones?

- What is meant by co-exist in REQ5?  Does this mean that a DMM solution does not break an existing one?  Or does it mean that it must inter-operate with existing ones?  Is this like IPv4 and IPv6 being incompatible, but can run concurrently on the same network?  Or does this mean there needs to be some mechanism for interaction (i.e., like NAT64)?

- I think REQ6 is incomplete.  A DMM solution can introduce new vulnerabilities, but it needs to provide ways to cope with those vulnerabilities.

6. I would like to avoid issues further along the publication chain, so I would like the editors to look at how the contributing authors are identified in the draft.  A good approach is described in the RFC Style Guide (https://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can be problematic.

Regards,
Brian