Re: [RTG-DIR] RtgDir review: draft-templin-ironbis-12.txt

["Fred L. Templin" <[e-mail]>]

Hello Ross,

Thank you for taking the time to look at this document. To your specific question
about what are the correct references, they are as follows:

  [AERO] = RFC6706
  [INTAREA-SEAL] = 'draft-templin-intarea-seal'
  [INTAREA-VET] = 'draft-templin-intarea-vet'

Please let me know if you need any further correspondence from me at this time.

Regards - Fred
[e-mail]





>________________________________
> From: Ross Callon <[e-mail]>
>To: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]> 
>Cc: "[e-mail]" <[e-mail]> 
>Sent: Friday, February 15, 2013 1:32 PM
>Subject: RtgDir review: draft-templin-ironbis-12.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://www.ietf.org/iesg/directorate/routing.html
> 
>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-templin-ironbis-12.txt
>Reviewer:        Ross Callon 
>Review Date:     February 15, 2013
>IETF LC End Date: February 18, 2013
>Intended Status: informational 
> 
>Summary: This document is basically ready for publication, but has a few minor issues and one major issue that needs to be resolved prior to publication. I recommend that the routing ADs discuss these issues, particularly the one major issue, with the
author. 
> 
>Comments: I found the document to be very readable and generally well written. There are only a few specific issues to resolve. 
> 
>Major Issue: 
> 
>I believe that the document should be experimental rather than informational. I suggest that the author discuss this with the routing ADs.  My comment below about manageability considerations is only one example of why experimental would be more appropriate
IMHO. 
> 
>Minor Issues: 
> 
>I am assuming that the RFC will carry the normal warning that this is not a standard of any kind, and is not currently a candidate to become a standard.
> 
>Section 19, references: 
> 
>19.2.  Informative References
> 
>   [AERO]     Templin, F., Ed., "Asymmetric Extended Route Optimization
>              (AERO)", Work in Progress, June 2011.
> 
>   ...
> 
>   [INTAREA-SEAL]
>              Templin, F., Ed., "The Subnetwork Encapsulation and
>              Adaptation Layer (SEAL)", Work in Progress, February 2011.
> 
>   [INTAREA-VET]
>              Templin, F., Ed., "Virtual Enterprise Traversal (VET)",
>              Work in Progress, January 2011.
> 
> 
>I don’t see how [INTAREA-VET], [INTAREA-SEAL], and [AERO] can be informational references. It is clear that you need these protocols in order to implement draft-templin-ironbis-12.txt, which implies that these need to be normative references. Also, I found
it difficult to know which version these references are to. Are they to, respectively, RFC 6706, RFC 5320, and RFC 5558?
> 
> 
>Also, I didn’t notice any discussion of manageability. This is a major issue that needs consideration. If the document status is “experimental” then I suppose that it is okay to start experiments without OAM solutions in place, but considerable thought
on this will be needed before deployments can be considered to be operational. Similarly I didn’t see a discussion of how operation continues through the failures of servers or lost packets. 
> 
> 
>  
>
>