Mach, Thank you very much for your quick review.
Regards, Alia On Mon, Jan 18, 2016 at 3:10 AM, Mach Chen <[email protected]> wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, please > see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Last > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-i2rs-traceability-06.txt > Reviewer: Mach Chen > Review Date: 2016/1/18 > IETF LC End Date: > Intended Status: Standard Track > > Summary: > I have some minor concerns about this document that I think should be > resolved before publication. > > Comments: > The document is well written and easy to read. > > > Minor Issues: > > 1. > The draft Intended status shows: Standards Track, but the Intended RFC > status in the datatracker is "Informational". I think the latter is true, > right? If so, please update it accordingly. > > > 2. > Section 5.2 > Client Address: This is the network address of the Client that > connected to the Agent. For example, this may be an IPv4 or IPv6 > address. [Note: will I2RS support interactions that have no > network address? If so this field will need to be updated.] > > IMHO, the Note should be deleted for a to-be-published document. The IPv4 > and IPv6 are just examples, the description here does not exclude other > possibilities. > > > 3. Section 5.2 > Requested Operation Data: This field comprises the data passed to > the Agent to complete the desired operation. For example, if the > operation is a route add operation, the Operation Data would > include the route prefix, prefix length, and next hop information > to be inserted as well as the specific routing table to which the > route will be added. The operation data can also include > interface information. > > Although the last sentence above is right, why do we need to emphasize the > "interface information" here? If there is no special intention, I'd suggest > to remove it. > > > 3. Section 5.2 > Transaction ID: The Transaction Identity is an opaque string that > represents this particular operation is part of a long-running > I2RS transaction that can consist of multiple... > > Here you specify that an Transaction ID is an opaque string, are there > other possibilities (e.g., uint) ? Since this is just an information model, > how the data type should be is specific to the data model, I'd suggest to > remove the data type limitation from this document. > > > Best regards, > Mach >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
