Re: [netconf] I-D Action: draft-ietf-netconf-udp-notif-08.txt

[Andy Bierman <[e-mail]>]

On Wed, Oct 26, 2022 at 5:02 AM Alex Huang Feng <
[e-mail]> wrote:

> Dear NETCONF WG,
>
> Some time ago we updated the UDP-notif draft with the changes shown in the
> previous mail. These changes will be presented in the next on-site IETF
> meeting.
>
> Also, after receiving some feedback about the observation domain id
> unicity from the dev team, we would like to propose this change in the next
> iteration of the draft (not published yet).
> This change in section 3.2 only clarifies that a Message-ID MUST be unique
> within the Observation-Domain-ID to avoid conflicts in the collector.
>
> OLD:
>
>    *  Observation-Domain-ID is a 32-bit identifier of the Observation
>       Domain that led to the production of the notification message, as
>       defined in [I-D.ietf-netconf-notification-messages <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-08#ref-I-D.ietf-netconf-notification-messages>].  This allows
>       disambiguation of an information source, such as the
>       identification of different line cards sending the notification
>       messages.  The source IP address of the UDP datagrams SHOULD NOT
>       be interpreted as the identifier for the host that originated the
>       UDP-Notif message.  Indeed, the streamer sending the UDP-Notif
>       message could be a relay for the actual source of data carried
>       within UDP-Notif messages.
>
>    *  The Message ID is generated continuously by the publisher of UDP-
>       Notif messages.  Different subscribers share the same Message ID
>       sequence.
>
>
> NEW:
>
>    *  Observation-Domain-ID is a 32-bit identifier of the Observation
>       Domain that led to the production of the notification message, as
>       defined in [I-D.ietf-netconf-notification-messages].  This allows
>       disambiguation of an information source, such as the
>       identification of different line cards sending the notification
>       messages.  The source IP address of the UDP datagrams SHOULD NOT
>       be interpreted as the identifier for the host that originated the
>       UDP-Notif message.  Indeed, the streamer sending the UDP-Notif
>       message could be a relay for the actual source of data carried
>       within UDP-Notif messages.  Note that if a relay is used,
>       Observation-Domain-ID unicity MUST be preserved in order to ensure
>       unicity of the Message-ID field described below.
>
>
It is not clear why this new MUST is needed.
It is up to the administrator to make sure all the 32-bit IDs in use are
unique.
The text already says not to rely on the source IP address and to rely
on this identifier instead. Maybe just highlight that this is why source IP
cannot be used,
without any unclear MUST requirements.

   *  The Message-ID is generated continuously by the publisher of UDP-
>       Notif messages.  A publisher MUST use different Message-ID values
>       for different messages generated with the same Observation-Domain-
>       ID.  Note that the main purpose of the Message-ID is to
>       reconstruct messages which were segmented using the segmentation
>       option described in section Section 4.1.  The Message-ID values
>       SHOULD be incremented by one for each successive message
>       originated with the same Observation-Domain-ID, so that message
>       loss can be detected.  Furthermore, incrementing the Message-ID by
>       one allows for a large amount of time to happen before the
>       Message-ID's are reused due to wrapping around.  Different
>       subscribers MAY share the same Message-ID sequence.
>
>

It is unclear what "different subscribers" means (last sentence).
The use of MAY implies some implementation requirements for the subscriber.

The first MUST is inconsistent with the text about wrapping around.
IMO the wrap-around should be the mandatory part.

The Message-ID value zero MUST NOT be used.
This allows implementations to tell if an ID has been set or not.
The same restriction for Observation-Domain-ID is needed.

Feedback is welcome.
>
> Best regards,
>
> Alex Huang Feng on behalf of the authors
>
>

Andy


> On 12 Sep 2022, at 15:20, Alex Huang Feng <[e-mail]>
> wrote:
>
> Dear NETCONF WG,
>
> Thanks again for the valuable feedback.
>
> We published a new draft-ietf-netconf-udp-notif-08 draft addressing the
> feedback received during the last IETF meeting and the ML.
>
> The following changes have been made to this iteration:
> - The requirements language has been updated
> - Secured layer for UDP-notif
> - Secured Layer MUST be used in unsecured networks
> - compacted sections 6.1, 6.2 as Sean Turner proposed
> - Add 0-RTT data MUST NOT be used
> - YANG module: made dtls container a presence container and removed
> DTSL1.2 bits
> - added 3 sub-sections in IANA considerations
> - Added third IANA registry to manage the shim header version as Rob
> proposed
> - Security considerations section has been moved to the end of the draft
> and a reference to “limited domains” RFC8799 is added
> - Updated the normative references
>
> There is a current discussion about the YANG module prefix and the ip
> format used in this YANG in another thread.
>
> We were also suggested to add an Operations Considerations section saying
> that the use of DTLS encryption would impact the performance of the
> protocol. Is that necessary? Or is this already evident?
>
> Also, after reading how HTTPS-notif YANG module is specified, we are
> asking ourselves if UDP-notif YANG module should be implemented the same
> way to be consistent within the architecture and use the already
> implemented ietf-subscribed-notif-receivers module. Any thoughts?
>
> Regards,
>
> Alex Huang Feng on behalf of the authors
>
> On 12 Sep 2022, at 14:45, [e-mail] wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Network Configuration WG of the IETF.
>
>       Title           : UDP-based Transport for Configured Subscriptions
>       Authors         : Guangying Zheng
>                         Tianran Zhou
>                         Thomas Graf
>                         Pierre Francois
>                         Alex Huang Feng
>                         Paolo Lucente
> Filename        : draft-ietf-netconf-udp-notif-08.txt
> Pages           : 24
> Date            : 2022-09-12
>
> Abstract:
>  This document describes an UDP-based notification mechanism to
>  collect data from networking devices.  A shim header is proposed to
>  facilitate the data streaming directly from the publishing process on
>  network processor of line cards to receivers.  The objective is to
>  provide a lightweight approach to enable higher frequency and less
>  performance impact on publisher and receiver processes compared to
>  already established notification mechanisms.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-notif/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-udp-notif-08
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>