Re: [netconf] [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-21

Per Hedeland <> Fri, 25 January 2019 18:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8CC213100F for <>; Fri, 25 Jan 2019 10:20:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kK3BjIDtXSsm for <>; Fri, 25 Jan 2019 10:20:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B942F131007 for <>; Fri, 25 Jan 2019 10:20:42 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1548440379; cv=none;; s=arc-outbound20181012; b=GHbzvB3jzXUVX0Ofc12f++0Na10q04mW9kN6IvKn7sZ9JiATwBZx7rgkMkVadoxa/nWxibvOgETbY fg6Sg8gMA5pUCfjhjQQIcRYppE3qgoZNzGnLsgii0WrXDDHkbbsisfHXPIwRpEBWuOgXVrXON7o010 Ns4fkMfDp6g4tyglPEvOL9tqmeyh7tgL3jmBZPVtwTh51R3E//sn6VBEikOR2DW6d9GkPBIUx10NU5 O8nG6pqFtGi0U8EEjdUuqriUEKY4YFZUIgEH/80PihUD9jVkPU+kUkxJNfv6J85LqLwp1nUj4JzXhz 1rFPHQN7S+e+Ph379vtIr8SjimxWUbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=01e3Gl8TKRwpfoht3dsGHCu6gu2+UfpELQj5EK7hEmI=; b=K/4dDwn3UESUp+UkZlZlkojSdLEHcqKrramyPTObfeWtAREjzP/UjfA729Ej2BrLlS9GdAhZVbXA3 1w48loyeDwK+OX3TGiWDr/M/9CqLGZf0QqlM55cy60a4SgXC2P7H0F+kbUzvMri6JZuGusZQRIh47I ORKIjXFL/bxz3Hn+8bKZeIpl9xwRLjLfo5Z39yujmpd2ojLCoaf2h1cwsulPnI1jHxs9h1fkiWIVox bxfbpt/BjA8etIEgTtoIaWNI0vHAxjsDQI+e57TMGpMRYzX13yZUsDRdb2ynNLtv7IBv6U6a5pJgMT 7h4f7Aa7Q9NjzcKe698ZpPYvhdkpCcQ==
ARC-Authentication-Results: i=1;; spf=none smtp.remote-ip=; dmarc=none; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=01e3Gl8TKRwpfoht3dsGHCu6gu2+UfpELQj5EK7hEmI=; b=MH+dT78hezF2yh4rqp2wDIWSqY6kpsas2Ors/u46sYsseC56Ak5Yw61t4yIOgioWaeuMz1DD4hzKE hb0AjiSdUnCrhXlzhn28N08XBU+VPkNnIleQU55cGCRMEN1ZP91XWEIlwtKG6P9RbeDd2fbTC3pSyn 9Ay8olHdpgl05C4uXVtSee1mZfh6saLY7Ojm49jMwQ06fVcK8aEHrNP5cmXrSzHfkvX1olkuVafXIv nLwuDn8l+p7WRHRJX4uJiCk/AKxpRb7j8RVQq+pQ1A0fY8ETBL2Z531qfLJM90JvDlVNHR8lAZY/3Y z3UAxIwmrl2uQi2R0AxetBd8cNBA4Cw==
X-MHO-RoutePath: cGVyaGVkZWxhbmQ=
X-MHO-User: c3495563-20cd-11e9-8a28-a1efd8da9a94
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from (unknown []) by (Halon) with ESMTPSA id c3495563-20cd-11e9-8a28-a1efd8da9a94; Fri, 25 Jan 2019 18:19:35 +0000 (UTC)
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x0PIJVZ0086296 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 25 Jan 2019 19:19:32 +0100 (CET) (envelope-from
To: "Eric Voit (evoit)" <>, Martin Bjorklund <>
Cc: "" <>, "" <>, "" <>
References: <> <> <> <> <>
From: Per Hedeland <>
Message-ID: <>
Date: Fri, 25 Jan 2019 19:19:30 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [netconf] [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-21
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Jan 2019 18:20:45 -0000

On 2019-01-25 16:41, Eric Voit (evoit) wrote:
>> From: Martin Bjorklund, January 25, 2019 10:30 AM
>> "Eric Voit (evoit)" <> wrote:
>>>> From: Martin Bjorklund, January 25, 2019 3:40 AM
>>>> "Eric Voit (evoit)" <> wrote:
>>>>>> "Eric Voit (evoit)" <> wrote:
>>>>>>>> "Eric Voit (evoit)" <> wrote:
>>>>>>>>>> From: Martin Bjorklund, January 24, 2019 9:40 AM
>>>>>>>>>> "Eric Voit (evoit)" <> wrote:
>>>>>>>>>>>> From: Martin Bjorklund, January 24, 2019 8:17 AM
>>>> [...]
>>>>>>>>>>>> Thinking some more, what is supposed to happen if
>>>>>>>>>>>> the client on the same session sends first an
>>>>>>>>>>>> establish-subscription with dscp 42, and then
>>>>>>>>>>>> another
>>>>>>>>>>>> establish-
>>>> subscription with dscp 10?
>>>>>>>>>>> This would be allowed.
>>>>>>>>>> On linux at least this is a sockopt, i.e., the option
>>>>>>>>>> applies to the socket, which means all packets on the
>>>>>>>>>> session.  So how is this supposed to be implemented if
>>>>>>>>>> different messages on the session should have different
>>>>>>>>>> dscp values?
>>>>>>>>>> Or is the
>>>>>>>>>> idea that you send the msg, flush all data from ssh/tls
>>>>>>>>>> to tcp, then flush the tcp buffers (not that easy...)?
>>>>>>>>>> Even if there's just one establish-subscription with a
>>>>>>>>>> dscp value, since it applies to the session it means
>>>>>>>>>> that all normal rpcs on this session will get the same dscp value.
>>>>>>>>>> It is not clear that this is the intention?
>>>>>> Did you miss these questions?
>>>>> With NETCONF, one DSCP will apply to single TCP session.  So there
>>>>> is no
>>>> issue.
>>>> The problem is if a client sends two establish-subscriptions with
>>>> different values for dscp on the same session.  Or even if the
>>>> client sends one
>>>> establish-
>>>> subscription with som dscp value, then the dscp will be applied to
>>>> all packets from other rpcs as well.
>>>> ... and even worse, with SSH channels you can have multiple NETCONF
>>>> session on the same TCP session, which means that the dscp value
>>>> applies to all packets in all NETCONF sessions sharing the same TCP
>>>> session.
>>>> I don't know what the right thing to do is.  Probably first agree
>>>> that this is in fact a problem, then maybe simply document this
>>>> somehow.
>>> I hadn't thought about multiple NETCONF SSH channels.  I agree
>>> something to guide developers is needed here.  The easiest fix is to
>>> recommend not supporting feature "dscp" with NETCONF.  (It shouldn't
>>> be absolutely prohibited as DSCP related RFC's such as RFC7657 embed
>>> text like "a single DSCP should be used for all packets in a TCP
>>> connection".)
>>> Here is the text I suggest is put into
>>> draft-ietf-netconf-netconf-event-notifications, Section 5:
>>> "The feature "dscp" SHOULD NOT be supported over NETCONF.  This will
>>> avoid the potential for out-of-order packet delivery of the set of all
>>> traffic within the TCP session."
>> I think this is a bit too limiting.  For configured subscriptions it can be perfectly
>> fine, since the server can ensure that there's a single TCP session to the receiver
>> in this case.  (I know we don't support configured subscriptions at the moment).
>> Perhaps we can say in the SN document:
>>    If a server that supports the "dscp" feature cannot guarantee that
>>    the only packets sent on an underlying transport session are from
>>    the subscription, then it should reject the subscription with a
>>    "dscp-unavailable" error.  This will avoid the potential for
>>    out-of-order packet delivery of the set of all traffic within the
>>    TCP session.
> This works for me.    I will put this in Section 2.3, directly after the sentence:
>     If the publisher supports the "dscp" feature, then a subscription
>     with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP
>     marking being placed within the IP header of any resulting
>     notification messages and subscription state change notifications.
>   unless I hear any objections on this thread.

I'm not sure why the "avoid out-of-order" rationale was presented.
There is no order "of the set of all traffic within the TCP session"
to be out-of. Regardless of DSCP, SSH peers will send data on the
channels (NETCONF sessions) in an order that depends, among other
things, on the rate of consumption of that data. They will preserve
order on any given channel, but will not consider order with respect
to other channels (arguably, not having to do that is the whole point
of having flow control at the SSH level).

I suggest simply dropping the "This will avoid ..." sentence.


> Eric
>> I think such text belongs to the SN document, since it may apply to other
>> transports than just NETCONF.
>> /martin
>>> With this text, a RESTCONF publisher can support the feature dscp.
>>> And if someone attempts to use dscp with a NETCONF subscription to the
>>> same publisher, the error "dscp-unavailable" can be sent.
>>> Eric
>>> ...
>>>> /martin
> _______________________________________________
> netconf mailing list