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!]
>
>> Minor issues:
>> -------------
>>
>>> 1. Introduction
>> ...
>>> Such networks
>>> are often referred to as Domains [RFC4726] and we adopt that
>>> definition in this document: viz.
>>>
>>> For the purposes of this document, a domain is considered to be any
>>> collection of network elements within a common sphere of address
>>> management or path computational responsibility. Examples of such
>>> domains include IGP areas and Autonomous Systems.
>>
>> Section 1.1.4. (Domain) repeats the definition in different words.
>> I think it would be better to fold the text from the Introduction
>> into 1.1.4.
>
> I disagree.
> I believe that an introduction needs to be stand-alone text without requiring
> reference to a terminology section that has not yet been read.
>
> The text in the Introduction is a direct quote and cannot be modified.
> The text in 1.1.4 is as near as possible to being a copy within the rules of
> abbreviation expansion.
> Effectively the two definitions are identical.
Yes, but I had to re-read them both to be sure of that. Actually I faced exactly
this problem recently in a draft of my own and fixed it with a forward
reference.
Up to you, this is just something that I found a bit awkward to read.
>>> 2.2. Client-Server Networks
>>
>> It may be considered a term of art in TE, but I found the phrase "server
>> network" very confusing at first. In my world, it means "a network containing
>> servers" but here it appears to mean "underlay network" or possibly "service
>> network". Anyway, if you want to use this phrase, I suggest defining it
>> precisely before using it.
>
> It is certainly a term of art in multi-layered networks. I did not do a
> comprehensive search, but found it in RFCs from 2005. You may also find it
> used a lot in the ITU-T where they have some experience of transport networks
> (hoping that in your world a transport network is not a TCP network :-)
Well, yes, I came across that particular ITU-T heresy many years ago.
>
> I think that you are saying that the description at the start of Section 2.2
> (that provides as a starting point the client-server relationship between
> networks) is not enough. I think we can manage a very brief definition for
> you to go in Section 1.1. Probably something like...
>
> Server Network
>
> A Server Network is a network that provides connectivity for another network
> (the Client Network) in a client-server relationship. A Server Network is
> sometimes referred to as an underlay network.
>
> Client Network
>
> A Client Network is a network that uses the connectivity provided by a Server
> Network. A Client Network is sometimes referred to as an overlay network.
That would be perfect.
>
>> Also, the text switches to "server domain" and uses "server layer". Then in
>> Figs 4, 5 and 6 the server domain has become "core domain". This terminology
>> is all a bit inconsistent.
>
> Yes, this is sloppy chat. Will scrub it. Ditto "client".
>
>>> 4.4. Requirements for Advertising Links and Nodes
>> ...
>>> This requires a routing protocol running between the nodes in the
>>> abstraction layer network. Note that this routing information
>>> exchange could be piggy-backed on an existing routing protocol
>>> instance, or use a new instance (or even a new protocol).
>>
>> It isn't obvious to me that it could be piggy-backed on an existing
>> instance in the general case; wouldn't that sometimes lead to duplicate
>> or ambiguous routes?
>>
>> A sentence in section 4.5 seems to suggest that ambiguity is very
>> possible:
>>
>>> That is, one address may mean one thing in the
>>> client network, yet the same address may have a different meaning in
>>> the abstraction layer network or the server network.
>>
>> Address mapping plus piggy-backed routing seems like a recipe
>> for disaster.
>
> I think this is resolved by the insertion of "...(subject to different
> switching capabilities applying to the links in the different networks, or to
> adequate address space separation)..." in the quoted text from 4.4 after "...
> could be piggy-backed on an existing routing protocol instance".
Sure.
Thanks,
Brian
>
>> Nits
>> ----
>>
>>> Figure 16 : A Network Comprising Three Peer Networks
>>
>> There's a missing | on node B2
>
> ack
>
>>> 10.3. Managing Interactions of Abstraction Layer and Server Networks
>> ...
>>
>>> The abstraction layer network needs a mechanism to tell the server
>>> This mechanism could also include the ability to request additional
>>> connectivity from the server layer, ...
>>
>> The first sentence of this paragraph is truncated.
>
> good catch
>
>>> 12. Security Considerations
>> ...
>>> Thus, the mechanisms in this document for
>>> inter-domain exchange of control plane messages and information
>>> naturally raise additional questions of security.
>>>
>>> In this context, additional security considerations arising from this
>>> document relate to the exchange of control plane information between
>>> domains.
>>
>> Those two sentences seem to say exactly the same thing.
>
> We like to demonstrate how seriously we take security by saying everything
> twice.
> We like to demonstrate how seriously we take security by saying everything
> twice.
>
> Once again, thanks for a very detailed reading.
>
> Adrian
>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
