[netmod] draft-ietf-netmod-syslog-model-14 Signing Options

[Clyde Wildes (cwildes)]

Hi,

As part of the last few steps before again calling for last call for 
draft-ietf-netmod-syslog-model-14, we are adding certificate support to the 
signing-options container. RFC 5848: Signed Syslog Messages is the RFC that 
governs this section.

The signing-options container resides within the remote action destination list 
section of the model. This means signing-options will be configurable for each 
remote destination.

RFC 5848 supports four signature groups as defined in section 4.2.3 Signature 
Group and Signature Priority of the RFC:
https://tools.ietf.org/html/rfc5848#section-4.2.3

We are proposing to limit our support to Signature Group 0 which covers the 
case for administrators who want all messages of a syslog stream to be signed 
and Signature Blocks to be sent to a single destination.  We believe this case 
covers all deployment scenarios that are commonly encountered.  

Support for Signature Groups 1 (each PRI value is associated with its own 
Signature Group), 2 (each Signature Group contains a range of PRI values), and 
3 (Signature Groups are negotiated through a private arrangement) could be 
added to the model later through augmentation.

Please let us know if you have any concerns about this.

Thanks,

Clyde


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Inconsistent config and state ordering in ietf-hardware

[William Lupton]

All,

I just noticed something minor but inconsistent with ietf-hardware. Whereas 
ietf-system and ietf-interfaces declare config before state, ietf-hardware is 
the other way round. If there’s no particular reason for this, perhaps they 
might be swapped?

% egrep '^   ? ?container' ietf-system.yang ietf-interfaces.yang 
ietf-hardware.yang 
ietf-system.yang:container system {
ietf-system.yang:container system-state {
ietf-interfaces.yang:  container interfaces {
ietf-interfaces.yang:  container interfaces-state {
ietf-hardware.yang:  container hardware-state {
ietf-hardware.yang:  container hardware {

Thanks,
William

PS, Perhaps this is moot, given the new data stores plans?___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] hi Alex, Eric and design team guys some comments for YANG-push and subscribed-notifications, please help to confirm

[Eric Voit (evoit)]

(Moving lots of people to 'BCC' so that this thread can traverse NETCONF & 
NETMOD filters as Walker originally intended.)

One more comment, see <>

From: Alexander Clemm, May 2, 2017 8:35 PM

Hi Walker, thank you for your review and comments, and Eric, for your excellent 
response, to which I have little to add except a few small items inline 
--- Alex

From: Eric Voit (evoit) [mailto:ev...@cisco.com]
Sent: Tuesday, May 02, 2017 9:52 AM
To: Zhengguangying (Walker) 
>; 
lud...@clemm.org; 
a...@clemm.org; 'Balazs Lengyel' 
>
Cc: netc...@ietf.org; 
netmod@ietf.org; Ambika Prasad Tripathy (ambtripa) 
>; 'Kent Watsen' 
>; Hector Trevino (htrevino) 
>; Einar Nilsen-Nygaard (einarnn) 
>; Guopeipei (Peipei Guo) 
>; Alberto Gonzalez Prieto 
(albertgo) >; 'Andy Bierman' 
>; 'Chisholm, Sharon' 
>; Yangang 
>; Alexander Clemm 
>; 'Susan Hares' 
>; Tim Jenkins (timjenki) 
>; 'Scharf, Michael (Nokia - DE)' 
>; Rohit pobbathi 
>; 'MehmetErsue' 
>; Mahesh Jethanandani (mahesh) 
>
Subject: RE: hi Alex, Eric and design team guys some comments for YANG-push and 
subscribed-notifications, please help to confirm

Hi Walker,

Thanks very much for the comments.   Some thoughts in-line.

From: Zhengguangying (Walker), May 2, 2017 9:25 AM
Hi Alex, Eric and all,

   I reviewed the latest Draft and have some comments, please help to confirm, 
thanks.

   For draft-ietf-netconf-yang-push-06:
1.   In section 4.1, the configured subscription receivers not sepcify 
which mechnism to connect to client, it's better define clearly, specify it 
should be call home protocol.
 I totally agree call home is necessary.  The two transport drafts 
currently have the call-home specified within them.  As we define the transport 
protocol per receiver, the appropriate call home mechanism for a platform 
transport should be automatically selectable.  I will clarify/improve the text 
in the subscribed-notifications draft to indicate this.
Is there something else needed at the protocol independent level?   At this 
point I don't know of any transport-independent call home behaviors 
unspecified, other than the need to add a context statement saying call home is 
necessary if transport isn't available for a queued push update message.  I 
don't think we should over specify this right now.  This is because for some 
transport connection types, call home doesn't need to be always-on.  E.g., HTTP 
implementations have the potential to scale differently than NETCONF if a 
configured subscription transport can be established ad-hoc only when a 
push-update is ready to go.   If there are other specific behaviors needed for 
call-home behavior, what are they?  Are these something that can vary by 
transport protocol and implementation?
In YANG model, "leaf period" 's unit is timeticks(1/100s), it difficult to 
understand for user, suggest to change the unit to millisecond.
 The common YANG types of RFC 6021 defines timeticks.  I am hoping not to 
change typedefs which are compliant with that RFC.   *However* if you see a 
business need to move to Milliseconds because you need a more granular time 
that hundredths of a second, we should discuss that.  Especially as hundredths 
is what SMIv2 uses, we should have some use cases which needs the extra 
granularity before making the change.  Do you have use cases which need 
millisecond-level subscription periods?
2.   for the "leaf dampening-period ", it's better to give one maxmum 
value, otherwise it may can not effective
 I think this what we are trying to say in the draft.  How about I 
improve the leaf dampening-period definition to:
"The shortest time duration which is allowed between the creation of 
independent yang object update messages.  Effectively this is the amount of 
time that needs to have passed since the last update."
3.   If the time is not enough to send all the data in a cycle, how to deal 
with the remaining data? Just postpone the next cycle or do not send the 
remaining data? If you do not send the