Sorry for the duplicate to the authors, mistyped the OPS-DIR address. /nco > On Dec 17, 2015, at 8:24 AM, Niclas Comstedt wrote: > > > Hi > > I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. > > ====== > > Status: Ready with issues > > I think the mechanism for collecting and recording SRLG info is fine. The way I read the whole draft I do have some minor concerns and feel there is a gap around an important area. It could be that some of these concerns are addressed elsewhere or intended not be in scope but including them here. > > Section 1.1, last paragraph. I don’t fully agree with this statement. You may not be able to derive the complete topology but given (to expand on your use case in here) enough CEs spread out you can conclude quite a bit, specifically more then what a provider would be ok with. > > Section 3.3. In the case where this is supported and collected isn’t the capability to update the SRLG information a ‘MUST’? Supporting the capability but without a mechanism to update it doesn’t seem useful > > Section 5.1, last paragraph. Its not entirely clear to me this paragraph (and the examples in the reference together with the rest of the doc) completely solves the original use case here. Or do see how to map and signal to ensure disjointness between the two paths of CE1<>CE2 as outside the scope of this doc? Which could be fine, i.e. this is focused on just providing a mechanism to record SRLG in the RRO. > > Section 6.1. Personally I would want this to be a ‘MUST’ for the exposure control. Mapping service is fine as ‘SHOULD’. > > > /nco