Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04

[Andy Bierman <[e-mail]>]

Hi,

It is unclear why this document needs to reinvent content types using a
4-bit ET field.

There is already a registry of integer mappings for CoAP
https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats

IMO this draft needs to (at least) define a header option for a 16-bit "CF"
field.
Implementations SHOULD provide a CF option if none of the standard ET types
apply.
One of the 16 standard ET values should mean "See CF option".


Andy





On Wed, Nov 17, 2021 at 11:31 AM Andy Bierman <[e-mail]> wrote:

>
>
> On Wed, Nov 17, 2021 at 3:03 AM Pierre Francois <
> [e-mail]> wrote:
>
>> Hello Andy,
>>
>> Thanks for the feedback, answers inline.
>>
>> Le mar. 16 nov. 2021 à 04:45, Andy Bierman <[e-mail]> a écrit :
>>
>>> Hi,
>>>
>>> I am wondering if there implementations of this draft already.
>>> IMO there are problems with in that prevent reasonable and
>>> optimal implementations.
>>>
>>
>> There is support of udp-notif publisher in VRP.
>> There is a C collector lib for udp-notif in
>> https://github.com/insa-unyte/udp-notif-c-collector
>>
>>
>>> 1) Use of UDP as the Application Message Framing
>>> UDP is a transport protocol.  Tightly coupling one
>>> NETCONF notification message to one UDP frame (+ fragments)
>>> is not very optimal.
>>>
>>
>> There is a segmentation option in the protocol, so a udp notif message is
>> not tightly coupled to a UDP frame.
>>
>
> But this segmentation is optional to implement.
> My point is that application protocols like NETCONF have their own message
> framing
> which does not exist here because the transport framing is used instead.
>
>
>>
>>
>>>
>>> 1A) wastes space in the UDP frame if the NETCONF notification
>>>     happens to be short
>>>
>>
>> I don't get it, I'm sorry. To me a UDP header + small udp-notif header is
>> rather short.
>>
>
> If I can fit 100 notification messages in 1 UDP frame then I save 99% of
> the redundant headers.
>
>
>
>>
>>
>>> 1B) imposes an application-level max-message-size
>>>
>>
>> Not with the segmentation option, do we agree?
>>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-4.1
>
> There can be 32767 segments of a max 65535 each: about 2G of data.
> However the segment-size is allowed to be smaller and segmentation is
> completely optional-to-implement.
>
> Application layer framing allows unlimited message size without any need
> to support UDP segmentation at all,
>
>
>
>>
>>>
>>> 2) Not Efficient for Streaming Servers (no Message Chunking)
>>> The application framing in NETCONF and RESTCONF (HTTP) is not
>>> coupled to any transport protocol. Instead, a sender may emit as
>>> many message chunks as desired. This is how a streaming server works.
>>> Content comes from many different sources and it is sent on-the-fly
>>> in chunks, instead of constructing large replies.
>>>
>>>     - Application framing allows multiple notifications in one UDP frame
>>>     - Application framing does not need a max-message-size.
>>>       Streaming servers often do not know the size of the data that will
>>> be sent
>>>       in a notification.
>>>
>>
>> I think we meet these goals. Let me think about this further.
>>
>
>
> I agree, by ignoring the idea that this protocol provides any normative
> information
> about the application layer protocol in use.  This draft should remove any
> hint
> that the application payload is defined in this document.  It is OK to say
> a different RFC (or spec) defines the content for a particular Encoding
> Type.
>
> The "notification" in Figure 1 implies that the payload is one NETCONF
> notification.
> The draft should be clear that there is no structure to the payload
> defined in this document.
>
>
>>
>>>
>>> Q1) Should proprietary encoding be used to support application-layer
>>> framing
>>>        or should the standard support it?
>>>
>>
>> I think we'd need to meet on this or else it will end up with thousands
>> of long emails ;)
>>
>
>
> I think the draft should let other documents define the exact content
> expected in the payload.
> I am used to application protocols defining specific message flows. Since
> this draft does
> not do that, it should not attempt to impose any rules on the application
> payload at all.
>
>
>
>>
>>
>>>
>>> 3) Protocol Message Encoding for CBOR
>>> The NETCONF notification message is not modelled in YANG.
>>> This is an open issue for YANG to CBOR encoding.
>>> https://github.com/core-wg/yang-cbor/issues/96
>>>
>>> The "notification" and "eventTime" elements do not have YANG definitions.
>>> SID assignments for these elements will be needed.
>>> This draft is the likely place for these SID assignment requests to
>>> the IESG and IANA.
>>>
>>
>> Shouldn't these be transport agnostic? I don't see why this would be
>> bound to udp-notif only and not, say, https-notif.
>>
>
> This is related to application/yang-data+cbor.
> A separate document for the SID assignments can be done.
>
>
>
>>
>>>
>>> 4) Subscription-ID Missing from Header
>>> It is quite possible for one message generator to create
>>> messages for multiple subscriptions.  The subscription-ID
>>> will be needed to dispatch notifications to subscribers correctly.
>>> The Observation-Domain-ID is not sufficient.
>>>
>>
>> Same answer as above, we understand obs-domain-id to be used in the
>> transport to meet load-balancing goals, but thought it would violate layers
>> to place subscription-IDs in the transport itself.
>>
>
>
> So I will put the Subscription-ID here instead I guess because a common
> use-case is to allow a Collector to support subscriptions from client
> applications.
> Only datastore subscriptions include a subscription-id, not event stream
> notifications.
>
>
>>
>>>
>>> 5) Private Encoding Option does not seem interoperable
>>>
>> The "Enc. Descr" field is completely opaque.
>>>
>>
>> Correct.
>>
>
>
> Then perhaps there is no need for this at all since it does not
> attempt to provide any interoperability?
>
>
>>
>>
>>> This field could be structured to provide the "ET number space owner"
>>> e.g, urn [wsp description]
>>>
>>
>> Mmm it's a valid option. Our opinion was that once you want it
>> interoperable, you should make it standard instead of private.
>> If the wg thinks we should kinda standardize private options, I'm
>> personally okay to add that to the draft.
>>
>
> Use of structured strings like URNs does not seem like a bad thing that
> should be discouraged.
> The ET field is not interopable if every implementation can define their
> own 4-bit values
> and there is no standard way to tell them apart. Perhaps just a domain
> name if a URN is too much of a burden.
>
>
>
>>
>>>
>>> Andy
>>>
>>
>> Thanks a lot for your comments,
>>
>> Pierre.
>>
>>
> Andy
>
>
>
>> Le mar. 16 nov. 2021 à 04:45, Andy Bierman <[e-mail]> a écrit :
>>
>>> Hi,
>>>
>>> I am wondering if there implementations of this draft already.
>>> IMO there are problems with in that prevent reasonable and
>>> optimal implementations.
>>>
>>> 1) Use of UDP as the Application Message Framing
>>> UDP is a transport protocol.  Tightly coupling one
>>> NETCONF notification message to one UDP frame (+ fragments)
>>> is not very optimal.
>>>
>>> 1A) wastes space in the UDP frame if the NETCONF notification
>>>     happens to be short
>>> 1B) imposes an application-level max-message-size
>>>
>>> 2) Not Efficient for Streaming Servers (no Message Chunking)
>>> The application framing in NETCONF and RESTCONF (HTTP) is not
>>> coupled to any transport protocol. Instead, a sender may emit as
>>> many message chunks as desired. This is how a streaming server works.
>>> Content comes from many different sources and it is sent on-the-fly
>>> in chunks, instead of constructing large replies.
>>>
>>>     - Application framing allows multiple notifications in one UDP frame
>>>     - Application framing does not need a max-message-size.
>>>       Streaming servers often do not know the size of the data that will
>>> be sent
>>>       in a notification.
>>>
>>> Q1) Should proprietary encoding be used to support application-layer
>>> framing
>>>        or should the standard support it?
>>>
>>> 3) Protocol Message Encoding for CBOR
>>> The NETCONF notification message is not modelled in YANG.
>>> This is an open issue for YANG to CBOR encoding.
>>> https://github.com/core-wg/yang-cbor/issues/96
>>>
>>> The "notification" and "eventTime" elements do not have YANG definitions.
>>> SID assignments for these elements will be needed.
>>> This draft is the likely place for these SID assignment requests to
>>> the IESG and IANA.
>>>
>>> 4) Subscription-ID Missing from Header
>>> It is quite possible for one message generator to create
>>> messages for multiple subscriptions.  The subscription-ID
>>> will be needed to dispatch notifications to subscribers correctly.
>>> The Observation-Domain-ID is not sufficient.
>>>
>>> 5) Private Encoding Option does not seem interoperable
>>> The "Enc. Descr" field is completely opaque.
>>> This field could be structured to provide the "ET number space owner"
>>> e.g, urn [wsp description]
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>> _______________________________________________
>>> netconf mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netconf
>>>
>>