Hi

my comments in line,

>> Same old discussion about framework versus architecture.
>> So you included the two terms to make me happy? ;-)
>>
>>  The I2RS working group works to develop a framework and architecture
>>  that will enable specific use cases, and lead to an understanding of the
>>  informational models and requirements for encodings and protocols for
>>  the I2RS interfaces.
>>
>> And now, we have a new term: architecture framework
>>
>> Jul 2013 : Request publication of an Informational document defining the
>> architecture framework
>>
>> I don't understand how you could have this "architecture framework"
>> before the use cases?
>> IMHO, the framework and architecture terms are not suitable. What you're
>> after is the explanation of the required building blocks in the use case
>> document(s).

I agree the use case should be clear in the doc before the framework,


>>
>> And then, the framework or architecture (pick up the term you want) will
>> explain:
>> to solve the use cases A, B, C, we need the building blocks D, E, F, with
>> the interfaces G, H, I, the data model J, K, L, and the protocol M.
>> However, that document will only exist in the next charter

I tried to explain that we should not follow documents in charter, but
follow approaches, however, the group wanted another way,

>> 3;
>> During the BoF, many use cases were discussed.
>> You asked: do we want to limit the use cases? Answer: yes
>> You asked: is 3 a reasonable number? Answer: yes
>> So how many do you have? It's not clear from the bullet points below " -
>> Tightly scoped key use cases for operational use of I2RS as follows:"
>

I agree to have 3 clear main use cases that can start the works' flow
for this year,

> We agree that the whole point of making such a list is that it will keep us
> away from ocean-boiling. We also agreed that I-Ds for other use cases would
> not be considered by the WG under this charter.
>
> Lastly we discussed how many RFCs might result from this list. My answer was
> that the worst case is 6 (one for each use case), but that it is possible
> (even likely) that authors would combine their work. It is too early to tell
> definitively which use cases might end up in a combined document (maybe all,
> maybe none), and there is nothing to say in the charter except for the
> existing statement about not adding to the use cases without rechartering.

If that is the situation then we need to specify those 6 or so cases,
or rechartering is a good idea in future,

AB
>
>> COMMENT:
>>
>> EDITORIAL:
>>
>> "Collocated" and "with the with" in
>>
>> While processes participating in the routing system are often colocated
>> with the with local forwarding elements, this isn't a necessary
>> condition.
>
> Yup.
> Thanks.
>
> Adrian
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to