Re: [Gen-art] Gen-ART Last Call review of draft-ietf-teas-interconnected-te-info-exchange-05

[Brian E Carpenter <[e-mail]>]

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:[e-mail]] 
> Sent: Wednesday, May 04, 2016 4:06 PM
> To: [e-mail]; [e-mail]; 'General Area Review Team' <[e-mail]>
> 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>