Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-03

[Wubo (lana)]

I support WG adoption.
I have read the draft and think it helps network auto-configuration and 
interoperability.
Thanks,
Bo

发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
发送时间: 2019年5月9日 5:52
收件人: netmod@ietf.org
主题: [netmod] Adoption poll for draft-wu-netmod-factory-default-03

This email begins a 1-week adoption poll for:

https://tools.ietf.org/html/draft-wu-netmod-factory-default-03
As we already have consensus from the previous poll to work on the problem, 
this poll primarily seeks for objections for using -03 as a basis for WG 
adoption (the document will be adopted if no objections are raised).  Of 
course, a show of support is also always encouraged.   All, please voice your 
support or objections before May 15.

Authors, already there have been good comments for how to improve the document. 
 However, please refrain from posting an update incorporating these comments 
until after this adoption poll closes, at which time the instruction will be to 
post a -00 with minimal changes, followed by a -01 incorporating the comments.

PS: the IPR poll conducted on Mar 25 is still considered valid.

Kent  // co-chair


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

[netmod] Adoption poll for draft-wu-netmod-factory-default-03

[Kent Watsen]

This email begins a 1-week adoption poll for:

https://tools.ietf.org/html/draft-wu-netmod-factory-default-03

As we already have consensus from the previous poll to work on the problem, 
this poll primarily seeks for objections for using -03 as a basis for WG 
adoption (the document will be adopted if no objections are raised).  Of 
course, a show of support is also always encouraged.   All, please voice your 
support or objections before May 15.   

Authors, already there have been good comments for how to improve the document. 
 However, please refrain from posting an update incorporating these comments 
until after this adoption poll closes, at which time the instruction will be to 
post a -00 with minimal changes, followed by a -01 incorporating the comments.

PS: the IPR poll conducted on Mar 25 is still considered valid.

Kent  // co-chair


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

Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

[Juergen Schoenwaelder]

On Wed, May 08, 2019 at 01:53:27PM +0200, Martin Bjorklund wrote:
> > 
> > Joe
> > 
> > If you look at the various RFC - YANG, Netconf, NMDA - they all define
> > the terms 'client' and 'server'; in the context, 'YANG server' seems
> > appropriate.
> 
> I agree w/ Joe.  I had the same comment when I read
> draft-ietf-netmod-yang-instance-file-format; it uses the term "YANG
> server".
> 
> I think these documents should import and use the term "server" from
> RFC 8342 where it is defined as:
> 
>o  server: An entity that provides access to YANG-defined data to a
>   client, over some network management protocol.
> 
> Perhaps we should have a term "YANG-based server" or something as an
> alias to "server" as defined above.  In some documents the short word
> "server" may sound too generic.  But "YANG server" doesn't sound right
> to me.
>

I find terms like 'YANG server' or 'YANG-based server' a bit confusing
since the server is not talking YANG (there is no YANG protocol) and
the server is also not sending/receiving YANG but YANG-defined data.

Unless there is a possibility of confusion, importing the 'server'
definition from RFC 8342 and using the terms 'server' is perhaps good
enough.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

[Martin Bjorklund]

tom petch  wrote:
> - Original Message -
> From: "Joe Clarke (jclarke)" 
> Sent: Monday, May 06, 2019 4:11 PM
> >
> > On May 6, 2019, at 08:06, Qin Wu
> mailto:bill...@huawei.com>> wrote:
> >
> > Hi, Chairs:
> > Sorry for late follow up, thanks Jurgen, Andy,Joe, Joel and all others
> for good comments, here is the update based on discussion and suggestion
> on the mailing list
> > The diff is:
> > https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-factory-default-03
> >
> > Hey, Qin.  I read through the changes, and I have a couple of
> additional comments.
> >
> > First, the term “YANG server” sounds odd to me.  I know what you mean,
> but I haven’t seen this defined before.  Maybe just saying a device or
> host is sufficient?
> 
> Joe
> 
> If you look at the various RFC - YANG, Netconf, NMDA - they all define
> the terms 'client' and 'server'; in the context, 'YANG server' seems
> appropriate.

I agree w/ Joe.  I had the same comment when I read
draft-ietf-netmod-yang-instance-file-format; it uses the term "YANG
server".

I think these documents should import and use the term "server" from
RFC 8342 where it is defined as:

   o  server: An entity that provides access to YANG-defined data to a
  client, over some network management protocol.

Perhaps we should have a term "YANG-based server" or something as an
alias to "server" as defined above.  In some documents the short word
"server" may sound too generic.  But "YANG server" doesn't sound right
to me.


/martin




> 
> Tom Petch
> 
> 
> 
> 
> 
> >
> > When you talk about the datastore to be reset, you list ,
> , and .  You state that each will receive the
> contents of .  The  DS wouldn’t need that.
> I think it would just be zeroed out.
> >
> > I think the RPC should reset any and all non-derived read-write
> datastores and not imply that a specific DS’s contents (i.e., the
> factory-default DS) is copied to them.  This way, other DSes would just
> be handled by this RPC based on implementation.  The 
> can exist as the factory default contents for .
> >
> > Joe
> >
> > We believe it is ready for second adoption poll. Thanks!
> >
> > -Qin (on behalf of authors)
> > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
> > 发送时间: 2019年4月9日 2:36
> > 收件人: netmod@ietf.org
> > 主题: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
> >
> > This message concludes the adoption poll for
> draft-wu-netmod-factory-default-02   The working group consensus
> supports working on the problem, but fundamental concerns were raised
> regarding the solution, specifically around reseting datastores versus
> resetting devices.  The chairs feel that these issues should be
> addressed before proceeding with the adoption.
> >
> > Authors, please update and resubmit the draft addressing the comments
> received during the adoption poll.  Another adoption poll will be issued
> when ready.
> > Thank you,
> > Kent (and Lou and Joel)
> >
> >
> >
> > On Mar 25, 2019, at 4:34 PM, Kent Watsen
> mailto:kent+i...@watsen.net>> wrote:
> >
> > This email begins a 2-week adoption poll for:
> >
> >
> > https://tools.ietf.org/html/draft-wu-netmod-factory-default-02
> >
> >
> > Please voice your support or objections before April
> 8.
> >
> >
> > Kent (and Lou)
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> 
> 
> 
> 
> 
> 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

[tom petch]

- Original Message -
From: "Joe Clarke (jclarke)" 
Sent: Monday, May 06, 2019 4:11 PM
>
> On May 6, 2019, at 08:06, Qin Wu
mailto:bill...@huawei.com>> wrote:
>
> Hi, Chairs:
> Sorry for late follow up, thanks Jurgen, Andy,Joe, Joel and all others
for good comments, here is the update based on discussion and suggestion
on the mailing list
> The diff is:
> https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-factory-default-03
>
> Hey, Qin.  I read through the changes, and I have a couple of
additional comments.
>
> First, the term “YANG server” sounds odd to me.  I know what you mean,
but I haven’t seen this defined before.  Maybe just saying a device or
host is sufficient?

Joe

If you look at the various RFC - YANG, Netconf, NMDA - they all define
the terms 'client' and 'server'; in the context, 'YANG server' seems
appropriate.

Tom Petch





>
> When you talk about the datastore to be reset, you list ,
, and .  You state that each will receive the
contents of .  The  DS wouldn’t need that.
I think it would just be zeroed out.
>
> I think the RPC should reset any and all non-derived read-write
datastores and not imply that a specific DS’s contents (i.e., the
factory-default DS) is copied to them.  This way, other DSes would just
be handled by this RPC based on implementation.  The 
can exist as the factory default contents for .
>
> Joe
>
> We believe it is ready for second adoption poll. Thanks!
>
> -Qin (on behalf of authors)
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
> 发送时间: 2019年4月9日 2:36
> 收件人: netmod@ietf.org
> 主题: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
>
> This message concludes the adoption poll for
draft-wu-netmod-factory-default-02   The working group consensus
supports working on the problem, but fundamental concerns were raised
regarding the solution, specifically around reseting datastores versus
resetting devices.  The chairs feel that these issues should be
addressed before proceeding with the adoption.
>
> Authors, please update and resubmit the draft addressing the comments
received during the adoption poll.  Another adoption poll will be issued
when ready.
> Thank you,
> Kent (and Lou and Joel)
>
>
>
> On Mar 25, 2019, at 4:34 PM, Kent Watsen
mailto:kent+i...@watsen.net>> wrote:
>
> This email begins a 2-week adoption poll for:
>
>
> https://tools.ietf.org/html/draft-wu-netmod-factory-default-02
>
>
> Please voice your support or objections before April
8.
>
>
> Kent (and Lou)
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>






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

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

Re: [netmod] Management Protocol Roles: Client/Server vs Manager/Agent

[Schwarz Albrecht (ETAS/ESY1)]

Thanks Randy for your comments and insights in the history of that management 
technologies!
Helpful, appreciated!
Albrecht


-Original Message-
From: netmod  On Behalf Of Randy Presuhn
Sent: 07 May 2019 05:37
To: netmod@ietf.org
Subject: Re: [netmod] Management Protocol Roles: Client/Server vs Manager/Agent

Hi -

On 5/6/2019 8:24 AM, Schwarz Albrecht (ETAS/ESY1) wrote:
.
> The relevant role semantics originate at application level (and not at 
> lower levels such as specific protocol layers), i.e., management 
> applications (= the primary scope of NETCONF/RESTCONF).
> That (native) roles are defined in ITU-T Recommendations X.701, 
> M.3010, M.3700, and others, and in RFCs 3411, 3413, 3512, and others (in case 
> of SNMP).
> Crucial, underlying concept is the Management Application Context 
> (often simply "context" in SNMP RFCs).

No.  The concept of "application context" as used in X.701 has no equivalent in 
the SNMP universe.  It's needed in X.701 because of the decision to permit the 
negotiation of roles upon establishment of an association.  In fundamentally 
connectionless SNMP, such negotiation would make no sense.

When the word  "context" is used in the SNMP universe, it refers to a 
completely different concept, one introduced primarily in order to work around 
deficiencies in the naming architecture resulting from MIB modules using the 
SMI.  See, for example, RFC 3415.

> A manager gots normally exclusive access to a specific management 
> application context.

Not true in either the CMIP nor in the SNMP universes.

> Multiple manager usually don't share the same application context

Not true in either the CMIP nor in the SNMP universes, and not true for either 
meaning of the word "context".

> (due to access conflicts, synchronization issues, etc).

No, that's why, for example, things like VACM and the the TestAndIncr textual 
convention are used in the SNMP world, and why a rudimentary locking facility 
has been present in Netconf since the early days.

> That's why the 1:N ratio of management manager to management agent(s).

That's not a realistic assumption for any kind of "industrial-strength" 
management architecture.

> (I'm aware that these high-level management roles are further refined 
> by e.g. considering the sub-roles of command generator, command 
> responder, notification originator, notification receiver), see RFC 
> 3413 or ITU-T X.703.)

I would not rely on X.703 as a source of terminological clarity in this forum.  
As an attempt to re-frame CMIP in terms of CORBA-speak, it long post-dates the 
split between the IETF and ISO/ITU communities.
As for RFC 3413, I think we were abundantly clear that the use of the 
"sub-roles" was fore purely expository purposes, and that whether there might 
be any corresponding division within an implementation would be, well, an 
implementation matter.

> Now, I had in mind that in client/server applications an application 
> context is normally not distributed over multiple servers (but I might 
> be wrong).
.

Consider, for example, aggregating management proxies.
The "disman" MIBS should provide ample examples.

Randy

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

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