Re: [Taps] [Editorial Errata Reported] RFC8095 (5285)

2018-03-12 Thread Mirja Kuehlewind (IETF) 
Ups… I’ll go ahead and verify this one!


> Am 12.03.2018 um 09:04 schrieb Gorry Fairhurst :
> 
> This Errata seems valid. Sorry that was not spotted.
> 
> Gorry
> 
> On 12/03/2018, 03:54, RFC Errata System wrote:
>> The following errata report has been submitted for RFC8095,
>> "Services Provided by IETF Transport Protocols and Congestion Control 
>> Mechanisms".
>> 
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5285
>> 
>> --
>> Type: Editorial
>> Reported by: Wesley Eddy
>> 
>> Section: section 3.1
>> 
>> Original Text
>> -
>> 3.1 Transport Control Protocol (TCP)
>> 
>> Corrected Text
>> --
>> 3.1 Transmission Control Protocol (TCP)
>> 
>> Notes
>> -
>> The acronym-expansion for TCP is incorrect in the section title, but is 
>> correct in other text within the document.
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>> 
>> --
>> RFC8095 (draft-ietf-taps-transports-14)
>> --
>> Title   : Services Provided by IETF Transport Protocols and 
>> Congestion Control Mechanisms
>> Publication Date: March 2017
>> Author(s)   : G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed.
>> Category: INFORMATIONAL
>> Source  : Transport Services
>> Area: Transport
>> Stream  : IETF
>> Verifying Party : IESG
> 

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

Re: [Taps] Mirja Kühlewind's No Objection on draft-ietf-taps-transports-usage-08: (with COMMENT)

2017-09-12 Thread Mirja Kuehlewind (IETF) 
Hi Gorry, 

see below.

> Am 12.09.2017 um 18:32 schrieb Gorry Fairhurst :
> 
> On 11/09/2017, 16:48, Mirja Kühlewind wrote:
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-taps-transports-usage-08: No Objection
>> 
>> 
>> 
>> 
>> --
>> COMMENT:
>> --
>> 
>> 
>> 
>> - I (still) don't understand why draft-ietf-taps-transports-usage-udp was 
>> kept
>> in a separate document, given there is even a separate empty section in this
>> doc. You basically have to stop reading there, go to the other doc, read it,
>> and come back. That doesn't make sense to me.
>> 
>> 
>> ___
>> Taps mailing list
>> ta...@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> I'll speak only to the last comment which was discussed in IETF-96.
> 
> The WG looked at this and there were pro's and con's in both a single 
> document, and two separate documents. In the end, the decision by the WG was 
> to publish the initial datagram analysis (UDP and UDP-L) as a separate 
> document, which cut them into smaller pieces and was more managebale, but the 
> WG would request the RFC-Ed to publish the two documents as a pair.

I just made the experience that I started reviewing 
draft-ietf-taps-transport-usage, then had to stop in the middle, read 
draft-ietf-taps-udp-usage and then return to the first one. The main problem is 
that draft-ietf-taps-transport-usage is so closely coupled to the other draft 
that is does not make sense stand-alone.

> 
> I see another advantage: Much of the API requirements for UDP is scattered 
> across various RFCs - and some implicit (RFCs that state a need to allow the 
> stack to do something, but do not indicate how it will be done). It was 
> thought a separate datagram document may have further utility for people as a 
> informative single reference on how to present a datagram API, beyond its 
> input to the TAPs transport design.

I’am actually not sure if there is any additional value in having this draft as 
a stand-alone draft, compared to just advise people to only read those sections 
they are interested in of a combined draft. The problem is, while the udp draft 
may make sense as a stand-alone draft, that’s not the case for this draft 
(draft-ietf-taps-transport-usage). 

I didn’t had a strong opinion about this before but now that I've read both 
draft as a whole together, I found it really uncomfortable to have this split 
up in two. However, this is only a comment and the authors/wg needs to decide.

Mirja

> 
> Gorry
> 

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

Re: [Taps] Eric Rescorla's No Record on draft-ietf-taps-transports-usage-08: (with COMMENT)

2017-09-11 Thread Mirja Kuehlewind (IETF) 
Hi Micheal, 

I also just caught that, assuming is was an copy-and-past left over; I think 
the best options are either:

***
[RFC7413] states that TCP implementations "MUST NOT use TFO by default, but 
only use TFO if requested explicitly by the application on a per-service-port 
basis" [RFC7413].
***
-> explicit citation

or 

***
TCP implementations can not use TFO by default, but only use TFO if requested 
explicitly by the application on a per-service-port basis [RFC7413].
***
-> no normative language

Mirja




> Am 11.09.2017 um 16:26 schrieb Michael Welzl :
> 
> Hi,
> 
> Sorry for the noise and for my ignorance regarding IETF style here -
> 
> this is indeed a mistake, in that the statement that you mention about TFO 
> was supposed to be a quote from RFC 7413, but doesn’t stand out as such  (so, 
> good catch, thanks!).
> 
> How do I make this clear enough to avoid a procedural problem - e.g., would 
> this be ok?
> ***
> TCP implementations MUST NOT use TFO by default, but only
> use TFO if requested explicitly by the application on a per-service-
> port basis [RFC7413].
> ***
> 
> Or would it have to be, e.g.:
> ***
> [RFC7413] states that TCP implementations MUST NOT use TFO by default, but 
> only
> use TFO if requested explicitly by the application on a per-service-
> port basis [RFC7413].
> ***
> 
> Thanks again,
> 
> cheers,
> Michael
> 
> 
> 
>> On Sep 11, 2017, at 4:13 PM, Eric Rescorla  wrote:
>> 
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-taps-transports-usage-08: No Record
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/
>> 
>> 
>> 
>> --
>> COMMENT:
>> --
>> 
>> I have not yet completed my review of this document, but I note that it is
>> targeted for Informative but also contains RFC2119 normative language, e.g.,
>> 
>> "TCP implementations MUST NOT use
>> TFO by default, but only use TFO if requested explicitly by the
>> application on a per-service-port basis."
>> 
>> If the intent is that this is to be Informational then this should be 
>> removed,
>> and if it's to be BCP, then it needs to go back to IETF-LC for that
>> 
>> 
> 
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

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