|10||(System)||Notify list changed from firstname.lastname@example.org, email@example.com to firstname.lastname@example.org|
|10||(System)||Document has expired|
|10||Martin Stiemerling||the decade wg was closed in 2012.|
|10||Martin Stiemerling||State changed to AD is watching from AD Followup|
|10||(System)||Sub state has been changed to AD Followup from Revised ID Needed|
|10||Akbar Rahman||New version available: draft-ietf-decade-arch-10.txt|
Here is the full AD review of the DECADE architecture draft.
This document is more an extended requirements document and does not contain sufficient insight …
Here is the full AD review of the DECADE architecture draft.
This document is more an extended requirements document and does not contain sufficient insight what the architectural details of DECADE are, can be, and what they are not.
The heavy usage of SHOULD/MUST shows that this document lists tons of requirements that are not necessarily listed in the requirements draft, where they are actually belonging.
Further, the document's intent is not to describe the DECADE system but a protocol architecture, I believe that there is a huge misunderstanding in what the scope of the document is.
In summary, the document fails to fit the scope of the architecture milestone of the WG.
This draft is sent back to the WG, as it is not in a state that warrants its publication as RFC.
The detailed review:
INTRODUCTION, paragraph 4:
> Content Distribution Applications (e.g., P2P applications) are widely
> used on the Internet and make up a large portion of the traffic in
> many networks. One technique to improve the network efficiency of
> these applications is to introduce storage capabilities within the
> networks; this is the capability provided by a DECADE (DECoupled
> Application Data Enroute) compatible system. This document presents
We do not work on 'DECADE systems'. Protocols only!
Section 1., paragraph 1:
> Content Distribution Applications, such as Peer-to-Peer (P2P)
> applications, are widely used on the Internet to distribute data, and
> they contribute a large portion of the traffic in many networks. The
> architecture described in this document enables such applications to
> leverage in-network storage to achieve more efficient content
> distribution (i.e. DECADE-compatible system). Specifically, in many
> subscriber networks, it can be expensive to upgrade network equipment
> in the "last-mile", because it can involve replacing equipment and
> upgrading wiring at individual homes, businesses, and devices such as
> DSLAMs (Digital Subscriber Line Access Multiplexers) and CMTSs (Cable
> Modem Termination Systems) in remote locations. Therefore, it may be
> cheaper to upgrade the core infrastructure, which involves fewer
> components that are shared by many subscribers. See [RFC6646] for a
> more complete discussion of the problem domain and general
I cannot see the relationship between core and access network
in the light of the above text.
Section 1., paragraph 4:
> The approach of this document is to define the core functionalities
> and protocol functions that are needed to support a DECADE-compatible
> system. The specific protocols are not selected or designed in this
The purpose of this document is to present an architecture.
Section 3.1., paragraph 1:
> Following[I-D.ietf-decade-reqs], the architecture consists of two
> protocols: the DECADE Resource Protocol (DRP) that is responsible for
> communication of access control and resource scheduling policies from
I still wonder why the split between DRP and SDT is not discussed and
described in a comprehensive way in this architecture document. The
current way looks rather half-baked and incomplete, as neither
in the requirements nor in this draft a real motivation for this
> a client to a server, as well as between servers; and Standard Data
> Transfer (SDT) protocol(s) that will be used to transfer data objects
> to and from a server. We show the protocol components figure below:
Section 3.2., paragraph 1:
> This section provides an example showing the steps in the
> architecture for a data transfer scenario involving an in-network
> storage system. We assume that Application End-Point B (the
> receiver) is requesting a data object from Application End-Point A
> (the sender). Let S(A) denote the DECADE-compatible storage server
> to which A has access. There are multiple usage scenarios (by choice
> of the Content Distribution Application). For simplicity of
> introduction, we design this example to use only a single DECADE-
> compatible server.
Wouldn't it be much better to start off with an example how
DECADE intergrates with an existing application protocol, such as, with P2P streamin or filesharing? I would expect this here at this place, even before going in the details about the flow as shown in the rest of the section. The example below is way too generic IMO.
Section 3.2., paragraph 2:
> The steps of the example are illustrated in Figure 2. First, B
> requests a data object from A using their native application protocol
> (see Section 5.1.2). Next, A uses the DRP to obtain a token. There
> are multiple ways for A to obtain the token: compute locally, or
> request from its DECADE-compatible storage server, S(A). See
> Section 6.1.2 for details. A then provides the token to B (again,
> using their native application protocol). Finally, B provides the
> token to S(A) via DRP, and requests and downloads the data object via
That is only about how a token is requested and for what
it is requested? What happens afterwards? This looks rather
incomplete. Furthermore, the description and reasoning for the SDT
is lacking completely.
Section 4.1., paragraph 1:
> A DECADE-compatible system SHOULD be able to support multiple Content
> Distribution Applications. A complete Content Distribution
This is an archtitecture draft and not an requirements draft. So,
this means that there shouldn't be any normative language that states
a requirement. Why is this not simply listed in the requirements
Section 4.1., paragraph 2:
> Application implements a set of "control plane" functions including
> content search, indexing and collection, access control, replication,
> request routing, and QoS scheduling. Different Content Distribution
some do this, but many don't. And I am not sure what this adds to
the text here.
> Applications will have unique considerations designing the control
> plane functions:
Section 4.1., paragraph 3:
> o Metadata Management Scheme: Traditional file systems provide a
> standard metadata abstraction: a recursive structure of
> directories to offer namespace management; each file is an opaque
> byte stream. Content Distribution Applications may use different
> metadata management schemes. For example, one application might
> use a sequence of blocks (e.g., for file sharing), while another
> application might use a sequence of frames (with different sizes)
> indexed by time.
The fact that some apps use sequences of blocks or sequences of
frames does not match with my understanding of meta-data. Did you
mean that the information about this is the meta-data? I guess so,
but the text isn't saying this.
Section 4.1., paragraph 5:
> Given the diversity of control plane functions, a DECADE-compatible
> system SHOULD allow as much flexibility as possible to the control
> plane to implement specific policies. This conforms to the end-to-
yet another requirement, but one that cannot test for compliance. How
do you test for flexibility? I can imagine what you are trying to
say, but it is not written here.
Section 4.1., paragraph 7:
> Decoupling control plane and data plane is not new. For example,
> OpenFlow [OpenFlow] is an implementation of this principle for
> Internet routing, where the computation of the forwarding table and
> the application of the forwarding table are separated. Google File
> System [GoogleFileSystem] applies the principle to file system
> design, by utilizing the Master to handle the meta-data management,
> and the Chunk servers to handle the data plane functions (i.e., read
> and write of chunks of data). NFSv4.1's pNFS extension [RFC5661]
> also implements this principle.
Why is this paragraph here??
Section 4.2., paragraph 1:
> A property of bulk content to be broadly distributed is that they
> typically are immutable -- once content is generated, it is typically
> not modified. It is not common that bulk content such as video
> frames and images need to be modified after distribution.
Is there any plan to support transcoded content?
Section 4.2., paragraph 2:
> Focusing on immutable data in the data plane can substantially
> simplify the data plane design, since consistency requirements can be
> relaxed. It also simplifies reuse of data and implementation of de-
I believe that this is not necessarily easing the data place
design, but the implementation is much easier, if data cannot be
changed. Anyhow, this is a minor point.
Section 4.2., paragraph 3:
> Depending on its specific requirements, an application may store
> immutable data objects in DECADE-compatible servers such that each
> data object is completely self-contained (e.g., a complete,
> independently decodable video segment). An application may also
> divide data into data objects that require application level
> assembly. Many Content Distribution Applications divide bulk content
> into data objects for multiple reasons, including (1) fetching
> different data objects from different sources in parallel; and (2)
> faster recovery and verification: individual data objects might be
> recovered and verified. Typically, applications use a data object
> size larger than a single packet in order to reduce control overhead.
I have not understood why this paragraph is in this section. This is
more about sort of data is expected to be stored in a DECADE server,
isn't it. It is not about ummutable data objects.
Section 4.2., paragraph 4:
> A DECADE-compatible system SHOULD be agnostic to the nature of the
> data objects and SHOULD NOT specify a fixed size for them. A
> protocol specification based on this architecture MAY prescribe
> requirements on minimum and maximum sizes by compliant
Again a requirement which should be listed somewhere else and only
be described here verbally but with more reasoning of it.
Section 4.2., paragraph 5:
> Immutable data objects can still be deleted. Applications may
> support modification of existing data stored at a DECADE-compatible
> server through a combination of storing new data objects and deleting
> existing data objects. For example, a meta-data management function
> of the control plane might associate a name with a sequence of
> immutable data objects. If one of the data objects is modified, the
> meta-data management function changes the mapping of the name to a
> new sequence of immutable data objects.
I do not understand the sentence starting with 'For example,
Section 4.3., paragraph 1:
> An object that is stored in a DECADE-compatible storage server SHALL
> be accessed by Content Consumers via a data object identifier.
Section 4.3., paragraph 2:
> A Content Consumer may be able to access more than one storage
> server. A data object that is replicated across different storage
> servers managed by a DECADE-compatible Storage Provider MAY still be
> accessed by a single identifier.
A requirement. And I am not sure that this is part of the protocol,
as it is more subject to policies of the content provider. However,
this isn't discussed at all.
Section 4.3., paragraph 3:
> Since data objects are immutable, it SHALL be possible to support
> persistent identifiers for data objects.
Section 4.3., paragraph 4:
> Data object identifiers for data objects SHOULD be created by Content
Section 4.3., paragraph 6:
> In particular, for some applications it is important that clients and
> servers SHOULD be able to validate the name-object binding for a data
> object, i.e., by verifying that a received object really corresponds
A requirement. But what is the requirement for the DECADE protocol?
Section 4.3., paragraph 8:
> A DECADE-compatible naming scheme follows the following general
It is good to say something about naming scheme, but the list below
is full of MAYs which are inappropriate here. Either you discuss
what a potential naming scheme is expected to deliver in a textual
way or you define normative requirements.
Section 4.4., paragraph 1:
> To support the functions of an application's control plane,
> applications SHOULD be able to know and coordinate which data is
> stored at particular servers. Thus, in contrast with traditional
Section 4.5.1., paragraph 2:
> The Storage Provider SHOULD delegate the management of the resources
> on a server to Content Providers. This means that Content Providers
> are able to explicitly and independently manage their own shares of
> resources on a server.
This is not a protocol requirement, but rather a use case that the
control of resources is performed outside the DECADE server.
Section 4.5.2., paragraph 2:
> The server SHOULD grant a share of the resources to a Content
> Provider or Content Consumer. The client can in turn share the
> granted resources amongst its multiple applications. The share of
A better model description with roles and functions would really
help to make the reader understand this. This would be the task of
this document, but I have a hard time to get all ends together.
> resources granted by a server is called a User Delegation.
Section 4.5.2., paragraph 3:
> As a simple example, a DECADE-compatible server operated by an ISP
> might be configured to grant each ISP Subscriber 1.5 Mbit/s of
> bandwidth. The ISP Subscriber might in turn divide this share of
> resources amongst a video streaming application and file-sharing
> application which are running concurrently.
This requires some model, e.g., a user login, application tokens. The
later is mentioned somewhere, but you do not provide a comprehensive
way to understand this. This is true for the majority of paragraphs
in this document. Instead of listing requirements, which do not
belong here, you better structure the document according what the
DRP and the SDT are supposed to do, how they interact, what roles
you are thinking about, etc.
Section 5.1., paragraph 1:
> Content Distribution Applications have many functional components.
> For example, many P2P applications have components and algorithms to
> manage overlay topology management, rate allocation, piece selection,
> etc. In this document, we focus on the components directly employed
> to support a DECADE-compatible system.
DECADE is supposed to work with many applications, but this draft
mainly assumes P2P filesharing or video streaming. However, either
you start off with the generalized case or you limit yourself to
a certain set of applications. But do make a choice.
Section 184.108.40.206., paragraph 1:
> A DECADE-compatible system decouples the control and the data
> transfer of applications. A Data Scheduling component schedules data
> transfers according to network conditions, available servers, and/or
> available server resources. The Data Index indicates data available
> at remote servers. The Data Index (or a subset of it) can be
> advertised to other clients. A common use case for this is to
> provide the ability to locate data amongst distributed Application
> End-Points (i.e., a data search mechanism such as a Distributed Hash
Neither this subsection nor any other part of this draft motivates
why the scheduler is part of the DECADE client. Couldn't built a
simple DECADE client without any data scheduler which is solely
driven by application requests to retrieve certain elements from
the DECADE server?
Section 5.2.2., paragraph 1:
> Applications will apply resource sharing policies or use a custom
> policy. Servers perform resource scheduling according to the
> resource sharing policies indicated by clients as well as configured
> User Delegations.
Why is such resource scheduling required? And what does it exactly
mean? Couldn't the DECADE server solely built on top of best
effort? Why do start off with the more complex case without even
describing the trivial case?
Section 5.3.2., paragraph 1:
> Recall from Section 5.1.1 that an Application typically includes its
> own naming and sequencing scheme. The DECADE-compatible naming
> format SHOULD NOT attempt to replace any naming or sequencing of data
> objects already performed by an Application; instead, the naming is
> intended to apply only to data objects referenced by DECADE-specific
A good point but it is a requirement that must be listed in the
requirements draft and not here.
Section 5.3.2., paragraph 2:
> An Application using a DECADE-compatible client may use a naming and
> sequencing scheme independent of DECADE-compatible names. The
What is a DECADE-compatible name? It is not defined anywhere.
Section 5.3.2., paragraph 3:
> DECADE-compatible client SHOULD maintain a mapping from its own data
> objects and their names to the DECADE-specific data objects and
> names. Furthermore, the DECADE-compatible naming scheme implies no
This is implementation specific, however, it is worth mentioning
but without the 'SHOULD'.
Section 5.3.3., paragraph 1:
> To illustrate these properties, this section presents multiple
This looks like an appendix, but in a more extend case, e.g., how
for instance bittorrent (or similar) would make use of DECADE server.
Section 5.4., paragraph 1:
> A key feature of a DECADE-compatible system is that a client can
> authorize other clients to store or retrieve data objects from the
> in-network storage. A token-based authorization scheme is used to
> accomplish this.
Why is this specified here without any proper evaluation? The
specification if it is a token-based system is usually not part
of an architecture, but part of the protocol specification. The
architecture document should say the use cases where you would need
authorization, etc, but not preclude on the solution space on the
Section 5.5., paragraph 1:
> A DECADE-compatible system SHOULD include a discovery mechanism
> through which clients locate an appropriate server.
Not a protocol requirement. I guess you wanted to say that a working
solution will require a discovery mechanism.
Section 5.5., paragraph 3:
> A discovery mechanism SHOULD allow a client to determine an IP
> address or some other identifier that can be resolved to locate the
> server for which the client will be authorized to generate tokens
> (via DRP). (The discovery mechanism might also result in an error if
> no such servers can be located.) After discovering one or more
> servers, a client can distribute load and requests across them
The load balancing aspect is orthogonal to the discover process.
Section 6., paragraph 1:
> This section presents the DRP and the SDT protocol in terms of
> abstract protocol interactions that are intended to be mapped to
> specific protocols. In general, the DRP/SDT functionality between a
> DECADE-compatible client-server are very similar to the DRP/SDT
> functionality between server-server. Any differences are highlighted
Why are you describe the protocol elements here already? This is
not the right document for describing a protocol.
Section 6.1.1., paragraph 1:
> On a single DECADE-compatible server, the following resources SHOULD
> be managed:
The 'SHOULD' does not make sense, and if the list is really important
it must appear in the requirements draft, but not here. Furthermore,
the list is incomplete, e.g., the storage resource will need much
more considerations. You might need to say that the resource need
different levels of control, such as per content provider and per
user. Who is in charge of managing the resources? Do you envision
that it is all managed by the server owner, or are delegations to
the content provider allowed? This information is completely missing.
Section 6.1.2., paragraph 1:
> A token SHOULD include the following information:
This section does not belong here, but it belongs into the protocol
specification. Furthermore, it should be up to the implementation
what the token contains. The protocol specification can of course
given guidance to the implementers.
Section 6.1.3., paragraph 1:
> DRP SHOULD provide a status request service that clients can use to
> request status information of a server.
This is a generic requirement of almost no use. What is the
status? It is detailed more below, but it reads again more like a
part of the protocol specification.
Section 220.127.116.11., paragraph 1:
> Access information MAY be provided for accounting purposes, for
> example, when Content Providers are interested in access statistics
> for resources and/or to perform accounting per user. Again, access
> to such information requires client authorization and SHOULD based on
> the delegation concept as described in Section 4.5. The following
> type of access information elements MAY be requested:
This section does not belong here, but it belongs into the protocol
specification. Parts of it should be discussed in the architecture
draft. However, is it required that this accounting information
is accessed as part of the DECADE protocols, or could you reuse
existing protocols for this?
Section 7.1., paragraph 2:
> This threat is addressed by the server's access control and resource
> control framework. Servers can require Application End-Points to be
> authorized to store and to download objects, and Application End-
> Points can delegate authorization to other Application End-Points
> using the token mechanism.
What happens if the client is allowed to access the resources,
but the client has an implementation bug and is exhausting all
resources on that server?
Section 7.1., paragraph 4:
> Denial of Service Attacks against a single server (directing many
> requests to that server) might still lead to considerable load for
> processing requests and invalidating tokens. SDT therefore MUST
> provide a redirection mechanism as described as a requirement in
Redirection will not solve DoS attacks. Invalid tokens are protocol
specific and should be discussed over there.
|09||Martin Stiemerling||State changed to AD is watching::Revised ID Needed from AD is watching|
Short AD review:
This document is more an extended requirements document and does not contain sufficient inside what the architectural details of DECADE are, can …
Short AD review:
This document is more an extended requirements document and does not contain sufficient inside what the architectural details of DECADE are, can be, and what they are not.
The heavy usage of SHOULD/MUST shows that this document lists tons of requirements that are not necessarily listed in the requirements draft, where they are actually belonging.
Further, the document's intent is not to describe the DECADE system but a protocol architecture. However, it fails on this aspect as it does not list what those aspects are.
There will be detailed comments per Section later on.
This draft is sent back to the WG for further work, as it is not in a state that warrants its publication as RFC.
|09||Martin Stiemerling||State changed to AD is watching from AD Evaluation|
|09||Martin Stiemerling||State changed to AD Evaluation from Publication Requested|
|09||Amy Vezza||State changed to Publication Requested from AD is watching|
We would like to submit draft-ietf-decade-arch-09 to IESG review. This draft is a product of the DECADE WG. Here is the link for this draft. …
We would like to submit draft-ietf-decade-arch-09 to IESG review. This draft is a product of the DECADE WG. Here is the link for this draft. http://tools.ietf.org/html/draft-ietf-decade-arch-09.
(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?
Informational. It is indicated in the title page header. As this document does not contain RFC2119 requirement languages. And this working group was chartered to do the informational analysis at the beginning, so every document for this stage is informational.
(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:
This document presents an architecture for accessing application agnostic in-network storage, discusses the underlying principles, and identifies key functionalities in the architecture for introducing a DECADE-compatible in-network storage system. In addition, some examples are given to illustrate these concepts.
Working Group Summary:
This document is a product of the DECADE WG, and was reviewed in working group meetings and via the email@example.com list. The consensus was made both in meeting and mailing list.
The document was reviewed by DECADE WG members, the WG Chairs, and key non-WG contributors, particularly by Konstantinos Pentikousis, Peng Zhang, Stephen Farrell, Carsten Bormann, David Harrington, David E Mcdysan, Borje Ohlman, and Ning Zong. The authors addressed all the comments, especially removed the optimization details from the architecture document. A few vendors and ISPs are interested in implementing/testing.
Haibin Song (firstname.lastname@example.org) is the document shepherd. Martin Stiemerling (email@example.com) is the responsible area director.
(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.
This document is in good shape, it covers the important features for data resource protocol and data transport protocol, and specifies the main characteristics of the data objects, access&authorization token and naming scheme. It is a good framework to design the application agnostic in-network storage used for content distribution. This document now presented is ready for publication.
(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
(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.
(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.
(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.
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
(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 support this document for publication. Individual protocol related documents have been proposed based on this architecture draft(although the re-chartering process has not been finished yet).
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.)
(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.
This document does not include any such formal language.
(13) Have all references within this document been identified as either normative or informative?
(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?
DECADE requirements draft (draft-ietf-decade-reqs-08) is a normative reference. These two documents are intended to go through the publication process together so as to avoid the reference to a unstable draft. The write-up for the DECADE requirements draft has been sent to the responsible area director.
(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
(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.
(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).
The document does not have any IANA considerations.
(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.
(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.
This document does not include any such formal language.
|09||Haibin Song||IETF state changed to Submitted to IESG for Publication from WG Document|
|09||Haibin Song||Annotation tag Doc Shepherd Follow-up Underway set.|
|09||Haibin Song||Changed protocol writeup|
|(System)||Posted related IPR disclosure: Haibin Song's Statement about IPR related to draft-ietf-decade-arch-09 belonging to THOMSON LICENSING|
|09||Haibin Song||The document write-up has been sent|
|09||Akbar Rahman||New version available: draft-ietf-decade-arch-09.txt|
|08||Haibin Song||Changed protocol writeup|
|08||Akbar Rahman||New version available: draft-ietf-decade-arch-08.txt|
|07||Akbar Rahman||New version available: draft-ietf-decade-arch-07.txt|
|06||Akbar Rahman||New version available: draft-ietf-decade-arch-06.txt|
|05||Martin Stiemerling||Responsible AD changed to Martin Stiemerling from David Harrington|
|05||David Harrington||State changed to AD is watching from AD Evaluation::AD Followup|
|05||(System)||Sub state has been changed to AD Followup from Revised ID Needed|
|05||Richard Alimi||New version available: draft-ietf-decade-arch-05.txt|
|04||David Harrington||State changed to AD Evaluation::Revised ID Needed from AD Evaluation.|
AD Review of draft-ietf-decade-arch-04
1) why not Proposed Standard?
2) in 3.2, there is discussion of an application's native protocol. what is a native protocol? …
AD Review of draft-ietf-decade-arch-04
1) why not Proposed Standard?
2) in 3.2, there is discussion of an application's native protocol. what is a native protocol? consider a terminology section.
3) in 4.1, "the decade architecture does not intend …"; first, an architecture doesn't intend anything. second, the second part of the sentence very much intends to enable arbitrary protocols.
4) in 4.1, "Also note that …" discusses implementation details. this whole sentence is unnecessary since support for decade is of course going to require implementation "adjustments". You might want to state this somewhat differently, if your goal is to say how this gets implemented is implementation-specific, but be careful here. We want interoperability and standardized behaviors, so we most certainly do want to require the implementation to meet certain requirements for compliance to the standard.
5) throughout the document there are numerous instances of "note that" that are purely superfluous. You ARE noting these points in the text, and you don't need to start the text with "note that".
6) in 4.2, "using the aforementioned data model" - I don't know what this means. in the IETF a "data model" tends to mean something specific - see rfc3444. So I don't think you have aforementioned any data model. If you did, I don't think you identified it as a data model when you described it, so it is unclear what you are referring to.
7) immutable means it cannot be modified. yet you sometimes talk about the blocks being modified; e.g. "it is not common that …"; in 4.2, you state that immutable blocks "do not not imply that contents cannot be modified. As I understand immutability, blocks that can be modified are not immutable. But you use the immutability property to justify decisions later in the architecture. Either you REQUIRE immutability of all blocks, or they are not immutable, and therefore their property of immutability CANNOT be used to justify later design decisions (unless you explicitly make the design decision conditional).
If you make immutability RECOMMENDED but not REQUIRED, that can have a significant impact on issues of complexity, security, interoperability, and so on. You really need to make a decision about immutability being required for compliant implementations, or just recommended. It is acceptable that some vendors choose to implement mutable blocks, but they should not claim compliance to the standard if the standard requires immutability. If you make mutability acceptable in complaint implementations, then there is a lot mre work to do to nail down the security aspects, the interoperability aspects, etc.
8) in 4.2, "do not specify a fixed size"; For interoperability, you should standardize either a mandatory-to-implement fixed size, with ways to handle other sizes, or you standardize how to specify the size (e.g., via a block size field in a standardized header or something, or a session description standard such as SDP, and possibly a size-negotiation handshaking phase).
At a minimum, you need to specify the minimum receive buffer size that MUST be supported in compliant implementations, and a maximum-allowed sending size in compliant implementations.
9) the arch might not specify fixed sizes, but specific protocols might. and since you are supporting the reuse of existing standard protocols, you certain cannot state that they cannot specify a fixed size.
10) in 4.5.1, you use the word "control" as a verb, "Applications control …", in the middle of discussions about resource control; using a different word (such as coordinates) might be better.
11) in 4.5.1, "isolation is required"; I think needs expansion, since there has been no discussion of isolation.
12) in 5, "related to protocol development" is too broad - "related to DECADE protocol development" would be better.
13) in 5.1. "manage … management" is redundant.
14) in 5.1, "piece selection" - yu haven't talked about pieces. are these blocks or something else?
15) in 5.1., "In supporting DECADE, it may be advantageous … to consider DECADE …" ; can we skip the marketing please?
16) 5.1.1 "DECADE is primarily designed to support" - simplify to "DECADE supports"
17) 5.1.1 "The specific implementation is entirely decidedly the application." So that means this is not part of DECADE at all. Ergo, maybe we shouldn't be discussing it here at all. and then we go on to say that sequencing and naming are not specified as part of decade. why are we discussing?
18) in 5.1.2, "may still use"???? why the still in this sentence? I think this whole paragraph needs to be reworked.
19) in 5.1.2, "in addition to decade as the data transport protocol". In 3.1, you said standard data protocols were used for data transport. I am of the impression, as area director, that existing standards are supposed to be used for decade data transport, not some new decade data transport.
20) One mandatory-to-implement data protocol should be identified for interoperability. This document doesn't seem to do that; the arch document would be the appropriate place to specify this mandatory-to-implement protocol, plus how to accommodate optional protocols (negotiation, session description, header fields, etc.)
21) in 5.1.3, it is important to note that "a decade client need not be embedded into an application"; it is NOT important to note that "It is important to note that", since we are already noting it. Please get rid of the "it is important to note that".
22) in 18.104.22.168, you refer to tit-for-tat; please provide a reference for tit-for-tat.
23) in 22.214.171.124 (and lots of other places, you state "The specific implementation is decide bh the application." Please make a general statement once, in the Introduction and lose this constant chorus.
24) in 126.96.36.199, "uses standard data transport protocols" - what does this actually mean? whose standards? can an implementation implement a proprietary protocol and still be compliant (as long as they also implement the mandatory-to-implement protocol)?
25) in 188.8.131.52, you mention "a distributed set of application end-points. I think this deserves a bit more discussion to make it clear what the requirements are for a distributed set of endpoints.
26) in 5.2.1, you start to get into specifying standard behaviors - "the decade server will provide access." If this is required behavior, then MUST may be appropriate, but if you are going to specify behaviors, then the doc needs to be a standard. You cannot specify required behaviors in an Info doc. Please be clear what is normative and what is informational.
27) in 5.2.2. s/Applications may apply their existing resource sharing policies/Applications apply resource charing policies/
28) in 5.2.3, RFC2119 keywords should really only be used if they are normative. instead of "may" please use "might".
Let's see if I can clarify use of normative. In an arch doc, you normally do not specify the requirements of the protocols, EXCEPT if this is necessary for on-the-wire communications between architectural components. How an internal component talks to another internal component is an implementation detail (an implementer might choose shared memory, global variables, interprocess communications, and a variety of implementation-specific optimizations). But if architectural components are expected to be developed by different vendors (e.g., clients and servers), and the on-the-wire format must be specified for interoperability, then rfc2119 language is called for. if you use rfc2119 language, please put it in caps so there is not question it is a rfc2119 keyword.
29) s/scheme multiple/scheme has multiple/
30) in 5.3.1, "this possibility is not considered in the current architecture" - then why are you mentioning it in the architecture document? If the architecture is being designed to permit this possible future extension, then the flexibility IS being considered as an requirement for the architecture.
31) in 5.3.2, what is a decade layer? I don't see that in the architectural diagrams, or any previous discussion. (f you want to show decade as an abstraction layer, I wouldn't objet, but do so clearly.)
32) "are not necessarily correlated" and "is expected to" conflict. What is the behavior expected of a standard-compliant architectural component?
33) by the time I hit 5.3.3, I am screaming at you …
"everything seems to be implementation-dependent. we are supposed to be writing a standard, and standards demand compliance. We should be specifying NOT what is implementation-dependent, but what is standard-compliant. What is an implementation required to provide for interoperable behaviors?
34) 184.108.40.206, what is a native protocol?
35) 220.127.116.11, "with which the it is communicating" what is "the it"?
36) s/size sizes/size/
37) "is unique" needs better scoping. Is unique within what scope - the internals of the implementation, the relationship between one client and one server? the m:n relationships of clients and servers in a deployment? the global Internet (in case multiple deployment instances somehow overlap each other)?
38) 5.4 discusses a referral approach. Existing standards already specify how to do referrals; why do we need another one? How about specifying one as mandatory-to-implement for compliance?
39) token-based authentication - existing protocols already specify token-based authentication and authorization (e.g. kerberos, radius, diameter); why do we need another one? How about specifying one as mandatory-to-implement for decade compliance?
40) 18.104.22.168 s/next, consider//
41) in 6, s/to mapped/to be mapped/
42) in 6, you bind the DRP and data transport, after you have been extolling the virtues of separation of the protocols. I think binding these is a bad idea, and would like to see the abstract discussion keep the separation. So using the http model with drp embedded in the headers may not be a good idea here. Please try addressing this using an example where the two are kept separate (and you can supplement it with an example where they are bound together). Providing only one example that requires binding the protocols seems a bad approach.
43) in 6, "the operations" - what operations? are you referring to data manipulation operations?
44) in 5.4, "Defining such policies is out of scope …" isn't necessary. Just say "A decade client may be denied access for other reasons, even if it posesses a valid token."
45) aaaaaargh! s/Note that//g, s/It is important to note that//g
46) in 6.1.2, "it is out of scope of this document …" - STANDARDIZE!!!!! It ****IS*** with scope of this document to specify standard inter-component behaviors and expectations. We should be specifying how to be conservative in what you send and liberal in what you accept.
47) in 6.1.2, "DRP may also define tokens" - too many options. STANDARDIZE!!! Is this "may also" a REQUIREMENT or a NICE-TO-HAVE.
48) in 6.2.1, "A server MAY" is this STD or Info? rfc2119 language?
49) in 6.2.1, "The naming scheme provides that the name is unique" - I disagree. This provides a hashing approach, and there can be conflicts. Discussion of what happens if the hash is not unique is not discussed, but it could create security holes, and violates privacy laws, and so on. Much more discussion is needed about the guarantee of uniqueness.
50) in 6.2.1, "A server MAT verify the integrity …" why not MUST?
51) in 6.1.x, ""specifies a set of attributes that SHOULD be supported" - why not MUST?
52) in 6.2, "An SDT … SHOULD offer a transport mode …" what is a transport mode? Does "offer a transport mode" mean there are other modes? Is this more options??? why is this not a MUST?
53) 6.2.1 and 6.2.2, PERMISSION denied - does this give an attacker insight into what is preventing them frm getting access, so they can better target their attacks (Cf: username/passwords; if a user supplies the wrong password, you don't want to report "wrong password", because that indicates you used a valid username); they can apply dictionary attacks to try to gain access to different parts of the system if they are denied access to certain parts.
54) s/Note, however, that//
s/It is assumed that//
55) 8.2, how can you deduplicate when each name is unique, and set by the client, and the server cannot change the name?
56) in 22.214.171.124, "S only needs to challenge R to verify" [it has the data]. Doesn't it also have to verify the data is the same data, to avoid giving the wrong data to the requester. (Would this make a nice vector for virus transmission?)
57) I have serious concerns that HTTP has already been chosen as the basis for a decade protocol, and the appendices only cover http, webdav, and cdmi. There are existing protocols that could be used, especially if the DRP is separate from the data transport protocol. I can envision AAA being useful as the DRP, since it already handles authentication, and authorization, and provisioning of resources such as bandwidth. I also have concerns about whether existing storage protocols, such as iSCSI or NFS, don't already have infrastructure ***pieces*** available that might be reusable for decade purposes. For implementations that already support iSCSI or NFS for storage manipulation, it seems wasteful to reinvent the wheel. But there is no discussion of how existing protocols, other than http-based with a binding between the DRP and SDT, could support decade environments.
|04||David Harrington||State changed to AD Evaluation from Publication Requested.|
(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 …
(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?
Haibin Song(firstname.lastname@example.org). I have reviewed this version. And I believe this version is ready for forwarding to the IESG 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?
The WGLC ended Saturday, 29th October 2011. The WGLC process provoked quite a lot of discussion on the architecture, resulting in new document 31 October 2011. A short discussion followed on the list to confirm the changes that resulted, and this is the document now presented here for IESG consideration.
(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?
(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.
(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?
The WG support this document for publication. Several individual protocol related documents have been proposed based on this architecture draft (although the re-chartering process has not been finished yet).
(1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.)
(1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html 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? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.
Yes. There are two warnings as follow, but they can be easily addressed before publication.
== You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/)
== Outdated reference: A later version (-05) exists of draft-ietf-decade-reqs-04
(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. Normative references are RFCs.
(1.i) Has the Document Shepherd verified that the document's IANA Considerations 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 [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?
Yes. The document does not have any IANA considerations.
(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?
The architecture does not include any such formal language.
(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:
This document presents an architecture for accessing application agnostic in-network storage, discusses the underlying principles, and identifies core components and protocols for introducing in-network storage for these applications.
Working Group Summary
This document is a product of the DECADE WG, and was reviewed in working group meetings and via the email@example.com list.
The document was reviewed by DECADE WG members, the WG Chairs, and key non-WG contributors, particularly by David E Mcdysan, Borje Ohlman, Akbar Rahman, Ning Zong and Dirk Kutscher.
|04||Cindy Morgan||Draft added in state Publication Requested|
|04||Cindy Morgan||[Note]: 'Haibin Song (firstname.lastname@example.org) is the document shepherd.' added|
|04||Haibin Song||Changed protocol writeup|
|04||Haibin Song||The write-up has been uploaded.|
|04||Haibin Song||Annotation tag Doc Shepherd Follow-up Underway set.|
|04||(System)||New version available: draft-ietf-decade-arch-04.txt|
|03||(System)||New version available: draft-ietf-decade-arch-03.txt|
|02||(System)||New version available: draft-ietf-decade-arch-02.txt|
|01||(System)||New version available: draft-ietf-decade-arch-01.txt|
|00||(System)||New version available: draft-ietf-decade-arch-00.txt|