Re: [dtn] Éric Vyncke's No Objection on charter-ietf-dtn-01-02: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Zahed and Rick,

Thank you for the explanations, I now better understand the QoS and tunnel concepts of DTN. For the former, the text could perhaps be improved by talking about 'priority' rather than the more generic 'QoS'. For the latter, indeed there is no need to cooperate with intarea WG.

If the OPS and SEC ADs are happy with the mix of OAM and Key Management, then it is obviously fine for me as well.

All in all, it is still a 'no objection' on my side for this fascinating piece of work.

Regards

-éric


On 06/12/2021, 11:16, "Zaheduzzaman Sarker" <[e-mail]> wrote:

    Hi Eric,

    With Rick's response (thanks Rick (and Ed)) here I think we are fine with the current wording in the charter ( of course the nits will be fixed). As described the QoS and Tunnel here have a very bounded meaning to DTN and I hope that will be more clear when the work is done. Right now, I don't feel that we have the desire to invent new words or add detailed explanation in the charter. 

    Thanks for your comments and questions. I hope we are on the same page now.

    BR
    Zahed

    On 2021-12-03, 18:16, "iesg on behalf of Rick Taylor" <[e-mail] on behalf of [e-mail]> wrote:

        Hi Eric,

        Thanks for the review, responses inline...

        > -----Original Message-----
        > From: Éric Vyncke via Datatracker [mailto:[e-mail]]
        > Sent: 30 November 2021 15:53
        > To: The IESG
        > Cc: [e-mail]; [e-mail]; [e-mail]
        > Subject: Éric Vyncke's No Objection on charter-ietf-dtn-01-02: (with
        > COMMENT)
        > 
        > Éric Vyncke has entered the following ballot position for
        > charter-ietf-dtn-01-02: No Objection
        > 
        > The document, along with other ballot positions, can be found here:
        > https://datatracker.ietf.org/doc/charter-ietf-dtn/
        > 
        > 
        > 
        > ----------------------------------------------------------------------
        > COMMENT:
        > ----------------------------------------------------------------------
        > 
        > I am puzzled by merging two different aspects in a single category:
        > "Operations, Administration and Management (OAM), and Key
        > Management". The
        > first one is clearly OPS but the second one is probably more in SEC area.

        Our current approach to Key Management is fairly simple - the cryptographic aspects are relatively simple and reuse work from SEC.  
        The reason for merging the topics is that although the key material and handling is reasonably simple, mechanisms for the distribution of key material is currently undefined, and the intention is to specify it using the OAM protocols we will define.

        > 
        > What is the meaning of QoS and QoS indication in such networks ?
        > 
        > Should there be a collaboration with intarea WG about the tunnels ?

        To quote from a private email with Ed Birrane (co-chair):

        "QoS"
        When a contact appears (either planned or opportunistically, there are (at least) two decisions that need to be made regarding what bundles flow in what order. (a) Which bundles go first, as a function of their priority and (b) whether bundles might be forwarded along multiple contacts to increase their likelihood of delivery.  For example, a bundle marked as critical for delivery might be transmitted on every next-hop for which a path to destination can be calculated. 
        Specifying how bundles should be annotated to enable these types of activities is the QoS portion, IIRC.

        "Tunneling"
        What is meant here, IIRC, is that there are times when a bundle needs to go to a waypoint BPA prior to the bundle destination BPA. This might happen, for example, if we need to make sure bundles go through a security acceptor prior to delivery.  Because the topology of a DTN might change significantly between bundle forwards, an active “tunnel” isn’t a good idea.  Instead, the way to achieve tunneling behavior is with bundle-in-bundle encapsulation (BIBE), where the original bundle is placed in an encapsulating bundle, and the encapsulating bundle destined for the desired waypoint.
        This type of tunnel is resistant to topological change and allows the encapsulating bundle to apply its own security to the encapsulated bundle. 
        I believe we decided in the WG that BIBE was going to be implemented as a convergence layer, and not some other extension to BPA behavior.

        > While there is a "Management Architecture and Protocols" milestone, there
        > are
        > none about "operations and administration" (to fully fit the OAM category).

        This is intentional, as we have agreed with the OPS AD to do a thorough review of our approach to management before specifying milestones for deliverables that might fail to make the cut.  Personal drafts documenting best practice for operations and administration exist, but their fate depends on the outcome of the 'general approach' review.

        > 
        > Some nits ?:
        > - s/in production by government and commercial organizations world-
        > wide./in
        > production by governments and commercial organizations world-wide./ -

        +1

        > s/Operations, Administration and Management/Operations, Administration,
        > and
        > Management/

        Oh, Oxford comma...   I shall defer to the standard used by the RFC Editors - someone please point to a relevant spec?

         - s/best practices learned from existing deployment./best
        > practices
        > learned from existing deployments./

        +1

        Thanks again for the good quality comments,

        Cheers,

        Rick