Re: [netconf] draft-ietf-netconf-udp-notif-10

[Jürgen Schönwälder <[e-mail]>]

On Mon, Aug 07, 2023 at 09:13:14AM +0200, Benoit Claise wrote:
> 
> 
> On 8/7/2023 8:50 AM, Jürgen Schönwälder wrote:
> > On Sat, Aug 05, 2023 at 08:44:16AM -0700, Andy Bierman wrote:
> > > Perhaps the scope of the draft should be narrowed so it is only intended to
> > > YANG Push or server events that do not need reliable delivery.
> > > 
> > So there needs to be at least a very tight applicability statement.
> Well, isn't obvious from the title and abstract? "UDP-based protocol for
> YANG notifications to collect data from networking devices"
> Is there really a need to say "the target of this draft is unreliable
> delivery of YANG Push b/c UDP is unreliable"

The discussion was about the question whether the 'segmentation
option' is necessary and whether the design will work in practice if
large messages (whatever large is) are necessary to support. And
part of the problem is likely that the Message Length field is a bit
unclear when it comes to segmentation.

   *  Message Length is the total length of the message within one UDP
      datagram, measured in octets, including the message header.

It is a bit unclear what an implementation is supposed to do if the
Message Length does not align with the UDP datagram length. I also
wonder how robust the protocol is against UDP injection attacks, if
it is used without DTLS (which seems to be an optional feature).

I personally also wonder why we need a private encoding option
consisting of a type field, a length field, and a variable length
field carrying an opaque encoding description). Why not have an
encoding field big enough to indicate the encoding used. Is the design
of the private encoding option is over engineered (a type, a length,
and a variable length opaque enc. description)?

I am also a bit puzzled by the 3-bit Ver field, for which I read:

   *  Ver represents the PDU (Protocol Data Unit) encoding version.  The
      current version value is 1.

Not sure what 'encoding version' means. Later on, I find an IANA
registry for "UDP-notif header version".

   These are the initial registrations for "UDP-notif header version":

     Value: 0
     Description: UDP based Publication Channel for Streaming Telemetry
     Reference: draft-ietf-netconf-udp-pub-channel-05

     Value: 1
     Description: UDP-based Transport for Configured Subscriptions.
     Reference: RFC-to-be

The term header version does not seem to appear elsewhere. So what is
this registry for? If it relates to the Ver field, the Ver field seems
to be carrying message type information, not an 'encoding version'
(and then 3 bits may be small if two code points are already
allocated, and you likely want a reserved one for extensions.

The more I read, the more questions I seem to have. The fundamental
question, however, is related to the message size reality that this
mechanism aims to support.

/js

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://constructor.university/>