Subject: RE: [NGO] hum ++

From: "Ersue, Mehmet" <[email-masked]>
Date: Wed, 1 Aug 2007 17:48:38 +0200

I support the documents on access control, schema advertisement 
and fine-grain locking and would like to review all. 

Although not in the draft charter Netconf over TLS would IMO 
round out the set of transport protocols and cause a broader 
usage of Netconf.

Regards, 
Mehmet 

> -----Original Message-----
> From: ext Andy Bierman [mailto:[email-masked]] 
> Sent: Monday, July 30, 2007 2:07 PM
> To: Balazs Lengyel
> Cc: [email-masked]
> Subject: Re: [NGO] hum ++
> 
> Balazs Lengyel wrote:
> > I'm willing to (co)author the fine-grained locking
> > draft and review the netconf monitoring and schema 
> advertising drafts.
> > 
> 
> I forgot to ++ for the netconf monitoring and schema/module 
> advertisement.
> 
> At first, I was not convinced the WG wanted a "debugging" schema.
> In previous WG meetings, it was dismissed as something
> that was only good for debugging the NETCONF protocol itself.
> (Yes, that would be the point of doing it...)
> Now I am glad to head "of course we need to debug the NETCONF
> protocol!" instead.
> 
> I have implemented a monitoring schema and module 
> advertisement mechanism,
> and can work as a co-author or reviewer these documents.
> 
> > Balazs
> 
> Andy
> 
> > 
> > David Partain wrote:
> >> Hi all,
> >>
> >> On Tuesday 24 July 2007 02:48:13 Romascanu, Dan (Dan) wrote:
> >>> The methodology that I was proposing in the nee bof 
> should be looked at
> >>> as an improved hum for each of the four items in the 
> charter proposal to
> >>> which I would suggest to add 'NETCONF over TLS' and 
> 'Network over SOAP
> >>> deployment' drafts (need one charter like bullets from 
> the authors).
> >>
> >> I believe that the three items first on the charter (finer-grained 
> >> locking, netconf monitoring and schema advertising) should be the 
> >> first focus for further work on netconf.  I believe all 
> three of these 
> >> have sufficient community interest to make their path 
> through the IETF 
> >> maze as painless as it can be.  There are already authors 
> committed to 
> >> the work, I believe there is operational need for all three, and I 
> >> will be willing to review all three.
> >>
> >> In short, if such a thing exists, I believe these are 
> low-hanging fruit.
> >>
> >> Even though I didn't put them on "my" list, I also would 
> encourage the 
> >> TLS and SOAP implementation folks to consider publishing 
> their work 
> >> either as Informational RFCs (SOAP?) or experimental RFC (TLS?) so 
> >> others have ready access to their work and can also 
> experiment with 
> >> TLS if they so desire.
> >>
> >>> Questions to ask:
> >>>
> >>> - is there a clear operational need or another proof of missing a
> >>> critical piece that requires doing the protocol work now?
> >>> - are there committed authors to do the work, as well as 
> (at least)
> >>> prototypes, or plans to prototype soon
> >>> - are there at least three independent reviewers for the work?
> >>>
> >>> When these questions are answered we can establish what 
> could become
> >>> part of a new (or renewed) charter.
> >>
> >> Cheers,
> >>
> >> David
> >>
> >>
> >> _______________________________________________
> >> NGO mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/ngo
> > 
> 
> 
> 
> _______________________________________________
> NGO mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ngo
> 

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 8 Aug 2007 15:34:35 -0400

Hi

I guess I have not responded to this chain yet. I see a strong need for
NETCONF monitoring and Schema advertisement. I also think partial
locking meets an important operational need. I think access control is
also important and should be included, depending on how much more the
working group is able to take on. I have interest in the other work
presented, but worry about scope.

I'm willing to work on all of these items in some capacity. Since we
have already done some work around schema discovery, I expect we should
be able to update that to serve a prototype of that work. The other I
will have to double check what can be done. Our model is typically a
vendor-specific implementation and then the RFC version when that is
available. I think what you are asking for is an extra implementation
in-between.

Sharon

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, July 23, 2007 8:48 PM
To: [email-masked]
Subject: [NGO] hum ++

The methodology that I was proposing in the nee bof should be looked at
as an improved hum for each of the four items in the charter proposal to
which I would suggest to add 'NETCONF over TLS' and 'Network over SOAP
deployment' drafts (need one charter like bullets from the authors). 

Questions to ask:

- are there committed authors to do the work, as well as (at least)

When these questions are answered we can establish what could become
part of a new (or renewed) charter. 

Dan

---

From: Andy Bierman <[email-masked]>
Date: Thu, 09 Aug 2007 05:44:09 -0700

> available. I think what you are asking for is an extra implementation

The most important thing (which you already identified) is
that we approach whatever problem from a solution-oriented,
and not layer-oriented.

If one were to approach the NETCONF data modeling issue
entirely from an Engineering perspective, ignoring all
the standards and product considerations for a moment,
it is absolutely clear that there needs to be some SMI glue
in place first, that all data models will use to
inter-operate.

1) Data organization (where does data live, 1 root, N roots, etc.)
2) Data naming (Object Identifier and Instance Identifier w/ Xpath)
3) Data model life-cycle and module management (ownership, change-control,
    version ID, module ID/discovery, etc.)

IMO, all of these features on the proposed charter need these
SMI features, especially the coupling between partial locking
and access control (one could even view partial locking as
just more access control).

A robust system architecture should be defined, in which
all the SMI, security, and operational requirements are
considered and understood.

Throwing together piece-meal features, and backing into
an architecture in random ways is not likely to result in
any success.  These same sort of issues had to be solved for
SNMP before MIBs were suitable for standardization.

We currently have no system architecture, other than
"do whatever you want with well-formed XML".  I fail to
see the standards value in this approach.

Andy