Hi Deborah, > To help the reader, I'd say section 6's and section 7's headers should be > more clearly labelled "An Abstraction Solution for Optical Domains and > Networks" and for section 7 "Abstraction in the User-to-Network Interface". > And these titles will align better with Section 8 "Abstraction in L3VPN...". > > Would that help?
Yes. Basically it needs to be clear that the architecture can be 100% implemented using current specifications, and that the possible extensions are not required for this (and are therefore not really part of the core of the BCP). Regards Brian On 05/05/2016 11:02, BRUNGARD, DEBORAH A wrote: > Hi Brian, > > Yes, much thanks for your careful read. I can understand your confusion on > our chosen track as we (authors, chairs, myself) went back and forth on it > though we debated if it should be standards track or BCP (or Applicability > Statement). > https://mailarchive.ietf.org/arch/msg/teas/YEv-68nB0LwBCOa3PcJR970pYhg > > Looking at your review, your question on why this is a BCP was based on a > sentence in section 5 which says that existing protocols <to be immediately > suitable> would need "some protocol extensions". Whereas in section 5.4, it > says this document will show how the existing protocols can be combined to > provide a solution with only minor modifications. > > So putting these sentences together one concludes the solution requires minor > modifications to the protocols. But the solution described in this document > doesn't require any modifications to the protocols. The solution is based on > abstracting information - section 6 uses abstraction combined with the 3rd > model for GMPLS networks, same for section 7 and section 8. > > The document was first proposed as standards track because it is a solution. > After discussion, it was agreed it really is a BCP as it is describing the > agreed best current approach for solving this problem, e.g. in section 6, it > is using RFC6827's (RFC6827 is a Proposed Standard) exchange of information > between different ASON architecture levels (not protocol exchanges). So it is > either standards track or a BCP as it is the WG's best solution for this > problem at this time. > > To help the reader, I'd say section 6's and section 7's headers should be > more clearly labelled "An Abstraction Solution for Optical Domains and > Networks" and for section 7 "Abstraction in the User-to-Network Interface". > And these titles will align better with Section 8 "Abstraction in L3VPN...". > > Would that help? > > Deborah > > > -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Wednesday, May 04, 2016 4:06 PM > To: [email protected]; > [email protected]; 'General Area > Review Team' <[email protected]> > Subject: Re: Gen-ART Last Call review of > draft-ietf-teas-interconnected-te-info-exchange-05 > > Hi Adrian, > > Just a few comebacks in line: > > On 04/05/2016 23:05, Adrian Farrel wrote: >> Hi Brian, >> >> Thanks for the time. > > Actually I read it with some interest, as I was wondering whether it > also provides a use case for the Anima WG. It probably could. > >> >>> Major issues: >>> ------------- >>> >>>> 5. Building on Existing Protocols >>> >>> I find it hard to read the introduction to this section and understand >>> why the draft is proposed for BCP rather than Informational. >> >> I will punt this question direct to the responsible AD since the authors >> brought the document forward as Standards Track and were "persuaded" by the >> WG chairs and responsible AD that it was a BCP as written. >> >> The only hint I will offer is that the authors would be grumpy about >> changing the content of the document to fit the publication track. Let's >> choose the track to fit the document :-) > > Understood. The IETF has never been very comfortable at accommodating > architecture > documents. But I don't really think the text would need changing, except for > 3 words > in the Abstract. The document stands on its own merits. Anyway, that's an > IESG question. > >> <snip> >> >> [except to note that the presence of normative references has nothing to do >> with whether a document is itself normative!] >> <snip> _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
