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

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.

   *  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.
Feedback is welcome.

Best regards,

Alex Huang Feng on behalf of the authors

> On 12 Sep 2022, at 15:20, Alex Huang Feng <alex.huang-feng@insa-lyon.fr> 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, internet-drafts@ietf.org 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
>> netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf