On 19. aug. 2014, at 18:13, Toby Moncaster <toby.moncas...@cl.cam.ac.uk> wrote:

> 
> On 19 Aug 2014, at 17:00, Michael Welzl <mich...@ifi.uio.no> wrote:
> 
>> +1.
>> 
>> 
>> Now, we can perhaps head on to the other charter changes related to this 
>> re-inserted milestone. I suggest the following undo's => I mean going back 
>> from THIS VERSION to the PREVIOUS VERSION, which is the version that went to 
>> IETF review:
>> 
>> THIS VERSION:
>> 2) Note that not all capabilities of IETF Transport protocols need to be 
>> exposed as Transport Services. This document will recommend the minimal set 
>> of Transport Services for inclusion in the abstract API. The resulting 
>> document will also provide guidance on making a choice among available 
>> mechanisms and protocols to obtain a certain Transport Service. 
>> 
>> PREVIOUS VERSION:
>> 2) Note that not all capabilities of IETF Transport protocols need to be 
>> exposed as Transport Services. This document will recommend the minimal set 
>> of Transport Services that support mechanisms must provide (such as those in 
>> work item 3). The resulting document will also provide guidance on making a 
>> choice among available mechanisms and protocols to obtain a certain 
>> Transport Service. 
>> 
> 
> I actually now think the previous version was a little clumsy. Also it sounds 
> really weird to start this item with a note… This makes me suspect this item 
> has been over-edited :)
> 
> Should we in fact say:
> 
> 2) Define the minimal set of Transport Services that must be provided by 
> mechanisms such as those to be specified in work item 3. The resulting 
> document will give guidance on choosing from available mechanisms and 
> protocols to provide a given Transport Service. Note that not all the 
> capabilities of IETF Transport protocols need to be exposed as Transport 
> Services.

I agree, much better, and it's not a semantic change, just language.


>> a bit below, for item 3 (last sentence):
>> 
>> THIS VERSION:
>> The associated milestone will be scheduled and work on this document will 
>> begin when the TAPS Transport Services have been specified. 
>> 
>> PREVIOUS VERSION:
>> Work on this document will begin when the TAPS Transport Services have been 
>> specified. 
> 
> Agreed since we will already have the milestone scheduled
> 
>> 
>> 
>> 
>> Not relevant to this particular discussion, but a suggested minor change 
>> nevertheless, for the out-of-scope list:
>> 
>> THIS VERSION:
>> - Extension, modification, or creation of existing IETF transport protocols 
>> 
>> PREVIOUS VERSION:
>> - Extension, modification, or creation of transport protocols 
>> 
>> 
>> The only problem I have here is that "the creation of existing.... 
>> protocols" does not sound very logical. I suggest to remove "existing”.
> 
> I’m guessing this was actually trying to cover 2 things: The creation of new 
> protocols and the extension or modification of existing protocols.

Yes, sure - but my point is that the word "existing" doesn't need to be there 
to convey that complete message.

Cheers,
Michael

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Reply via email to