OK, thanks for your prompt response! Best regards, Mach
> -----Original Message----- > From: rtg-dir [mailto:[email protected]] On Behalf Of Susan Hares > Sent: Monday, January 18, 2016 7:10 PM > To: Mach Chen; [email protected] > Cc: [email protected]; [email protected]; > [email protected] > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-i2rs-traceability-06.txt > > Mach: > > Thank you for the review. It is very helpful to the I2RS Work. The draft > was > changed to standards track after the information tracker was initialized. I > will > work with Alia Atlas to get this changed. > > As for the rest of the comments, the authors (Joe, Gonzalo or Carlos) will > answer. > > Sue > > -----Original Message----- > From: Mach Chen [mailto:[email protected]] > Sent: Monday, January 18, 2016 3:10 AM > To: [email protected] > Cc: [email protected]; [email protected]; > [email protected] > Subject: RtgDir review: draft-ietf-i2rs-traceability-06.txt > > 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
