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

Reply via email to