Re: [auth48] [IAB] AUTH48: RFC-to-be 9419 <draft-iab-path-signals-collaboration-03> for your review

[Mirja Kuehlewind <[e-mail]>]

Resending from this address as gmail now doesn’t like Ericsson mail anymore…


> On 2. Jun 2023, at 16:10, Mirja Kuehlewind <mirja.kuehlewind=[e-mail]> wrote:
> 
> Hi all,
> 
> My replies inline as well.
> 
> I also noticed in the xml that you replaced “evolvability” with "ability for protocols to evolve”. I think this is not wrong but I see evolvability actually as a technical term that has been established in the mean time. What do the other authors think?
> 
> 
>> On 2. Jun 2023, at 11:29, Ted Hardie <[e-mail]> wrote:
>> 
>> Some personal answers to the questions in-line.
>> 
>> On Thu, Jun 1, 2023 at 7:53 PM <[e-mail] <mailto:[e-mail]>> wrote:
>>> Authors,
>>> 
>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>> 
>>> 1) <!--[rfced] Would it be correct to rephrase the document title as
>>> follows for clarity (i.e., "Application Considerations for"
>>> instead of "Considerations on Application -")?
>>> 
>>> Original:
>>>    Considerations on Application - Network Collaboration 
>>>    Using Path Signals
>>> 
>>> Perhaps:
>>>    Application Considerations for Network Collaboration 
>>>    Using Path Signals
>>> -->
>>> 
>> No, I don't think this change is correct; both the network and applications have this to consider here so it isn't just "application considerations".
> 
> This change would not be correct. It’s about the collaboration between application and networks.
> 
>> 
>>  
>>> 
>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. 
>>> -->
> 
> I can’t really come up with any additional keys. I think the titles covers everything well.
>>> 
>>> 
>>> 3) <!--[rfced] Informative reference RFC 793 has been obsoleted by RFC 9293.
>>> Per Section 4.8.6 in the RFC Style Guide (RFC 7322), we recommend
>>> replacing RFC 793 with RFC 9293.  May we update the reference? 
>>> 
>>> Original:
>>>    For instance, on-path elements use various fields of the 
>>>    TCP header [RFC0793] to derive information about 
>>>    end-to-end latency as well as congestion. 
>>> 
>>> Suggested: 
>>>    For instance, on-path elements use various fields of the 
>>>    TCP header [RFC9293] to derive information about 
>>>    end-to-end latency as well as congestion. 
>>> -->
>>> 
>> 
>> I am okay with this change.
> 
> Yes, thanks!
> 
>>> 
>>> 4) <!-- [rfced] FYI, to make the two categories easier to read, we
>>> formatted this text as a list. Please let us know of any
>>> objections.
>>> 
>>> Original:
>>>    Many protocol mechanisms throughout the stack fall into one of two
>>>    categories: authenticated and private communication that is only
>>>    visible to a very limited set of parties, often one on each "end";
>>>    and unauthenticated public communication that is also visible to all
>>>    network elements on a path.
>>> 
>>> Current:
>>>    Many protocol mechanisms throughout the stack fall into one of two
>>>    categories:
>>> 
>>>    *  authenticated private communication that is only visible to a
>>>       very limited set of parties, often one on each "end", and
>>> 
>>>    *  unauthenticated public communication that is visible to all
>>>       network elements on a path.
>>> -->
>>> 
>> 
>> I prefer the first, but if the other authors prefer the second I can agree.  The reason I prefer the first is that we were not trying to create an exhaustive enumeration but were introducing a common pair of patterns.  I believe the list form will tend to lure the reader into assuming the list is exhaustive when it is not.  I do recognize that this is explicitly disclaimed, which is why I will agree if the other authors prefer this formulation.
> 
> I agree with Ted and also prefer the original version.
> 
>> 
>> 
>>  
>>> 
>>> 5) <!--[rfced] To avoid using "ensures" and "ensuring" in close
>>> proximity, may we rephrase this sentence as follows?
>>> 
>>> Original:
>>>    For instance, QUIC replaces TCP for various applications and ensures
>>>    end-to-end signals are only accessible by the endpoints, ensuring
>>>    evolvability [RFC9000]. 
>>> 
>>> Perhaps:
>>>    For instance, QUIC replaces TCP for various applications so that
>>>    end-to-end signals are only accessible by the endpoints, ensuring
>>>    the ability to evolve [RFC9000]. 
>> 
>> I don't think this captures the sense of the original. Would this work:
>> 
>> For instance, QUIC replaces TCP for various applications and protects end-to-end signals so that they are only accessible by the endpoints, ensuring evolvability [RFC9000].
> 
> Ted proposals looks good!
>> 
>>  
>>> -->
>>> 
>>> 
>>> 6) <!-- [rfced] FYI, to make the items easier to read, we formatted this text
>>> as a list. Please let us know of any objections.
>>> 
>>> Original:
>>>    Authentication and trust
>>>    must be considered in both directions: how endpoints trust and
>>>    authenticate signals from network path elements, and how network path
>>>    elements trust and authenticate signals from endpoints.
>>> 
>>> Current:
>>>    Authentication and trust 
>>>    must be considered in both directions:
>>> 
>>>    *  how endpoints trust and authenticate signals from network path
>>>       elements and
>>> 
>>>    *  how network path elements trust and authenticate signals from
>>>       endpoints.
>>> -->
>>> 
>> 
>> I do not personally believe this improves the readability.
> 
> I also prefer the original.
> 
>> 
>>  
>>> 
>>> 7) <!--[rfced] We rephrased this sentence for clarity; please let us know
>>> of any objections.
>>> 
>>> Original:
>>>    This section also provides some examples and explanation 
>>>    of situations that not following the principles can lead to.
>>> 
>>> Current:
>>>    This section also provides some examples and explanation 
>>>    of situations that can arise when the principles are not 
>>>    followed.
>>> -->
>>> 
>> 
>> Would this work:
>> 
>> This section also provides examples and explores the consequences of not following these principles in those examples.
> 
> Ted’s proposal works for me.
> 
>> 
>> 
>>  
>>> 
>>> 8) <!-- [rfced] Please clarify "they are from and to other parties". Would "they
>>> are coming from and going to other parties" help clarify?
>>> 
>>> Original:
>>>    Note that these communications are conceptually
>>>    independent of the base flow, even if they share a packet; they are
>>>    from and to other parties, rather than creating a multiparty
>>>    communication.
>>> 
>>> Perhaps:
>>>    Note that these communications are conceptually
>>>    independent of the base flow, even if they share a packet; they are
>>>    coming from and going to other parties, rather than creating a 
>>>    multiparty communication.
>>> -->
>>> 
>> 
>> I am fine with this change.
> 
> Okay.
> 
>> 
>>  
>>> 
>>> 9) <!-- [rfced] We would like to rephrase this information as follows for
>>> clarity and to reduce redundancy. Please let us know if the
>>> preferred text is agreeable or if you prefer otherwise.
>>> 
>>> Original:
>>>    The goal is that any information should be provided knowingly, for a
>>>    specific purpose, sent in signals designed for that purpose, and that
>>>    any use of information should be done within that purpose.  And that
>>>    an analysis of the security and privacy implications of the specific
>>>    purpose and associated information is needed.
>>> 
>>> Perhaps:
>>>    The goal is that any information should be provided knowingly for a
>>>    specific purpose, sent in signals designed for that purpose, and used 
>>>    within that purpose. In addition, an analysis of the security and privacy 
>>>    implications of the specific purpose and associated information is needed.
>>> -->
>>> 
>> I think the phrasing of the second sentence is an improvement, but I prefer the original formulation of the first sentence.  In particular, I believe "should be provided knowingly, for a specific purpose," is clearer that the two elements are distinct characteristics of the goal.
> 
> Yes, knowingly and specific purpose are two separate points. 
> 
>> 
>>> 
>>> 10) <!--[rfced] Would it be clearer to say "Even if" instead of "Whether"
>>> and "it does not mean" instead of "it does not follow" in the
>>> following sentence?
>>> 
>>> Original:
>>>    Whether a communication is with an application server or
>>>    network element that can be shown to be associated with a particular
>>>    domain name, it does not follow that information about the user can
>>>    be safely sent to it.
>>> 
>>> Perhaps:
>>>    Even if communication with an application server or network
>>>    element can be shown to be associated with a particular
>>>    domain name, it does not mean that information about the
>>>    user can be safely sent to it.
>>> -->
>>> 
>> I don't have a suggestion here--Jari, any thoughts on this one?
>> 
> 
> This change would not be correct. The domain name part only applies to network elements. 
> 
>>  
>>> 
>>> 11) <!--[rfced] The following list is not parallel. Please let us know if
>>> the perhaps text captures the intended meaning.
>>> 
>>> Original:
>>>    And of course we need to choose such cases where the collaboration 
>>>    can be performed safely, is not a privacy concern, and the 
>>>    incentives of the relevant parties are aligned.
>>> 
>>> Perhaps:
>>>    And, of course, we need to choose such cases where the collaboration 
>>>    can be performed safely, there are no privacy concerns, and the 
>>>    incentives of the relevant parties are aligned.
>>> -->
>>> 
>> 
>> Would this work:
>> 
>> And of course we need to choose cases where the collaboration 
>>    can be performed safely, where it is not a privacy concern, and where the 
>>    incentives of the relevant parties are aligned.
>> 
>> The original had a specific focus:  the collaboration not being a privacy concern.  I'm a bit concerned that "there are no privacy concerns" is too expansive.  
> 
> Agree this Ted.
>>  
>>> 
>>> 12) <!--[rfced] Some of the bullet points in this list begin with a
>>> complete sentence and some begin with a fragmented sentence (see
>>> #4, #5, and #6). Please let us know if/how we may make the list
>>> parallel.
>>> 
>>> Original:
>>>    *  Some forms of collaboration may depend on business arrangements,
>>>       which may or may not be easy to put in place. 
>>> 
>>>    *  Secure communications with path elements is needed as discussed in
>>>       Section 2.3. 
>>> 
>>>    *  The use of path signals for reducing the effects of denial-of-
>>>       service attacks, e.g., perhaps modern forms of "source quench"
>>>       designs could be developed. 
>>> 
>>>    *  Ways of protecting information when held by network elements or
>>>       servers, beyond communications security.
>>> 
>>>    *  Sharing information from networks to applications.  
>>> 
>>>    *  Sharing information from applications to networks. 
>>> 
>>>    *  Data privacy regimes generally deal with more issues than merely
>>>       whether some information is shared with another party or not.
>>> 
>>>    *  The present work has focused on the technical aspects of making
>>>       collaboration safe and mutually beneficial, but of course,
>>>       deployments need to take into account various regulatory and other
>>>       policy matters. 
>>> -->
>>> 
>> I think  these should all be complete sentences; if everyone agrees, I can take a whack at some suggested expansions.
> 
> Sure we can do that. Please do!
>> 
>>  
>>> 
>>> 13) <!--[rfced] For better readability, we combined the following
>>> sentences. Please let us know if this is accurate or please clarify. 
>>> 
>>> Original:
>>>    Finding practical ways for this has been difficult, both from the 
>>>    mechanics and scalability point view.  And also because there
>>>    is no easy way to find out which parties to trust or what trust
>>>    roots would be appropriate.
>>> 
>>> Current:
>>>    Finding practical ways for this has been difficult, both from the 
>>>    mechanics and scalability point of view, especially because there
>>>    is no easy way to find out which parties to trust or what trust
>>>    roots would be appropriate.
>>> -->
>>> 
>> 
>> I think it would be "partially because" rather than "especially because" if you combine them, but I'm okay with keeping "especially because" if others prefer it.
> 
> Yes, are that “partially because” would be better.
>> 
>>  
>>> 
>>> 14) <!--[rfced] May we rephrase this sentence for clarity as follows?
>>> 
>>> Original:
>>>    Data privacy regimes generally deal with more issues than merely
>>>    whether some information is shared with another party or not.
>>> 
>>> Perhaps:
>>>    Data privacy regimes generally deal with multiple issues, not just
>>>    whether or not some information is shared with another party.
>>> -->
>>> 
>> 
>> I am okay with this change.
> 
> Okay for me.
>> 
>>  
>>> 
>>> 15) <!-- [rfced] IAB Formatting
>>> 
>>> a) Please review the guidance for IAB documents
>>> <https://www.rfc-editor.org/materials/iab-format.txt> and let us know if any
>>> changes are needed.
>>> 
>>> Note that if you include an "IAB Members at the Time of Approval" section
>>> (since this document has IAB consensus), it will appear before the 
>>> Acknowledgements section and will list the members listed on <https://www.iab.org/about/iab-members/> unless you specify otherwise. 
>>> -->
> 
> Yes, please include this section.
> 
>>> 
>>> 
>>> 16) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
>>> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>> and let us know if any changes are needed.
>>> 
>>> Note that our script did not flag any words in particular, but this should 
>>> still be reviewed as a best practice.
>>> -->
> 
> Thanks!
> 
> Mirja
> 
> 
>>> 
>>> 
>>> Thank you.
>>> 
>>> RFC Editor/st/kc
>>> 
>>> 
>>> On Jun 1, 2023, at 11:52 AM, [e-mail] <mailto:[e-mail]> wrote:
>>> 
>>> *****IMPORTANT*****
>>> 
>>> Updated 2023/06/01
>>> 
>>> RFC Author(s):
>>> --------------
>>> 
>>> Instructions for Completing AUTH48
>>> 
>>> Your document has now entered AUTH48.  Once it has been reviewed and 
>>> approved by you and all coauthors, it will be published as an RFC.  
>>> If an author is no longer available, there are several remedies 
>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>> 
>>> You and you coauthors are responsible for engaging other parties 
>>> (e.g., Contributors or Working Group) as necessary before providing 
>>> your approval.
>>> 
>>> Planning your review 
>>> ---------------------
>>> 
>>> Please review the following aspects of your document:
>>> 
>>> *  RFC Editor questions
>>> 
>>>   Please review and resolve any questions raised by the RFC Editor 
>>>   that have been included in the XML file as comments marked as 
>>>   follows:
>>> 
>>>   <!-- [rfced] ... -->
>>> 
>>>   These questions will also be sent in a subsequent email.
>>> 
>>> *  Changes submitted by coauthors 
>>> 
>>>   Please ensure that you review any changes submitted by your 
>>>   coauthors.  We assume that if you do not speak up that you 
>>>   agree to changes submitted by your coauthors.
>>> 
>>> *  Content 
>>> 
>>>   Please review the full content of the document, as this cannot 
>>>   change once the RFC is published.  Please pay particular attention to:
>>>   - IANA considerations updates (if applicable)
>>>   - contact information
>>>   - references
>>> 
>>> *  Copyright notices and legends
>>> 
>>>   Please review the copyright notice and legends as defined in
>>>   RFC 5378 and the Trust Legal Provisions 
>>>   (TLP – https://trustee.ietf.org/license-info/).
>>> 
>>> *  Semantic markup
>>> 
>>>   Please review the markup in the XML file to ensure that elements of  
>>>   content are correctly tagged.  For example, ensure that <sourcecode> 
>>>   and <artwork> are set correctly.  See details at 
>>>   <https://authors.ietf.org/rfcxml-vocabulary>.
>>> 
>>> *  Formatted output
>>> 
>>>   Please review the PDF, HTML, and TXT files to ensure that the 
>>>   formatted output, as generated from the markup in the XML file, is 
>>>   reasonable.  Please note that the TXT will have formatting 
>>>   limitations compared to the PDF and HTML.
>>> 
>>> 
>>> Submitting changes
>>> ------------------
>>> 
>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
>>> the parties CCed on this message need to see your changes. The parties 
>>> include:
>>> 
>>>   *  your coauthors
>>> 
>>>   *  [e-mail] <mailto:[e-mail]> (the RPC team)
>>> 
>>>   *  other document participants, depending on the stream (e.g., 
>>>      IETF Stream participants are your working group chairs, the 
>>>      responsible ADs, and the document shepherd).
>>> 
>>>   *  [e-mail] <mailto:[e-mail]>, which is a new archival mailing list 
>>>      to preserve AUTH48 conversations; it is not an active discussion 
>>>      list:
>>> 
>>>     *  More info:
>>>        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>> 
>>>     *  The archive itself:
>>>        https://mailarchive.ietf.org/arch/browse/auth48archive/
>>> 
>>>     *  Note: If only absolutely necessary, you may temporarily opt out 
>>>        of the archiving of messages (e.g., to discuss a sensitive matter).
>>>        If needed, please add a note at the top of the message that you 
>>>        have dropped the address. When the discussion is concluded, 
>>>        [e-mail] <mailto:[e-mail]> will be re-added to the CC list and 
>>>        its addition will be noted at the top of the message. 
>>> 
>>> You may submit your changes in one of two ways:
>>> 
>>> An update to the provided XML file
>>> — OR —
>>> An explicit list of changes in this format
>>> 
>>> Section # (or indicate Global)
>>> 
>>> OLD:
>>> old text
>>> 
>>> NEW:
>>> new text
>>> 
>>> You do not need to reply with both an updated XML file and an explicit 
>>> list of changes, as either form is sufficient.
>>> 
>>> We will ask a stream manager to review and approve any changes that seem
>>> beyond editorial in nature, e.g., addition of new text, deletion of text, 
>>> and technical changes.  Information about stream managers can be found in 
>>> the FAQ.  Editorial changes do not require approval from a stream manager.
>>> 
>>> 
>>> Approving for publication
>>> --------------------------
>>> 
>>> To approve your RFC for publication, please reply to this email stating
>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>>> as all the parties CCed on this message need to see your approval.
>>> 
>>> 
>>> Files 
>>> -----
>>> 
>>> The files are available here:
>>>   https://www.rfc-editor.org/authors/rfc9419.xml
>>>   https://www.rfc-editor.org/authors/rfc9419.html
>>>   https://www.rfc-editor.org/authors/rfc9419.pdf
>>>   https://www.rfc-editor.org/authors/rfc9419.txt
>>> 
>>> Diff file of the text:
>>>   https://www.rfc-editor.org/authors/rfc9419-diff.html
>>>   https://www.rfc-editor.org/authors/rfc9419-rfcdiff.html (side by side)
>>> 
>>> Diff of the XML: 
>>>   https://www.rfc-editor.org/authors/rfc9419-xmldiff1.html
>>> 
>>> The following files are provided to facilitate creation of your own 
>>> diff files of the XML.  
>>> 
>>> Initial XMLv3 created using XMLv2 as input:
>>>   https://www.rfc-editor.org/authors/rfc9419.original.v2v3.xml 
>>> 
>>> XMLv3 file that is a best effort to capture v3-related format updates 
>>> only: 
>>>   https://www.rfc-editor.org/authors/rfc9419.form.xml
>>> 
>>> 
>>> Tracking progress
>>> -----------------
>>> 
>>> The details of the AUTH48 status of your document are here:
>>>   https://www.rfc-editor.org/auth48/rfc9419
>>> 
>>> Please let us know if you have any questions.  
>>> 
>>> Thank you for your cooperation,
>>> 
>>> RFC Editor
>>> 
>>> --------------------------------------
>>> RFC9419 (draft-iab-path-signals-collaboration-03)
>>> 
>>> Title            : Considerations on Application - Network Collaboration Using Path Signals
>>> Author(s)        : J. Arkko, T. Hardie, T. Pauly, M. Kuehlewind
>>> WG Chair(s)      : 
>>> Area Director(s) : 
>>> 
>>> 
>>> 
>