Subject: [NGO] hum ++

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 24 Jul 2007 02:48:13 +0200

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:

- 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. 

Dan

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

---

From: David Partain <[email-masked]>
Date: Tue, 24 Jul 2007 23:11:52 +0200

Hi all,

> 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.

> part of a new (or renewed) charter.

Cheers,

David

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 28 Jul 2007 12:47:24 +0200 (CEST)

David Partain <[email-masked]> wrote:
> further work on netconf.

I agree with this.  I'm willing to (co)author the fine-grained locking
draft and review the other ones.

I also plan to implement the fine-grained locking capability.

In my agent I have implemented a data model for monitoring, which I
will send to the list as input to the discussion.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 28 Jul 2007 04:22:20 -0700

> will send to the list as input to the discussion.

I also support standards-track RFCs for these work items.
Another work item will be required to complete it however.
At a minimum, a document on NETCONF Data Model Naming
(Object Identifiers and Instance Identifiers) must be standardized.
This is needed for partial locking to specify the data to lock.

Perhaps an entire SMI is needed soon, but I think the naming piece
should be separated out for faster completion of partial locking.

I can contribute as an author/reviewer on the data modeling documents,
and a reviewer on the partial locking document.  I also plan
to implement the access control model and partial locking.

I support standards track publication of the NETCONF over TLS
work item as an optional transport for NETCONF.  IMO, the more devices
that can run NETCONF, the better.  Small devices that already have
HTTPS configuration software do not generally have SSH-based CLI or XML
operator interfaces, and it may not be cost-effective to add SSH
just for NETCONF.

I cannot contribute to this document however. IMO, it should
be done in the security area.

> /martin

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Jul 2007 14:35:08 +0200

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> 
> work item as an optional transport for NETCONF.  IMO, the 
> more devices that can run NETCONF, the better.  Small devices 
> that already have HTTPS configuration software do not 
> generally have SSH-based CLI or XML operator interfaces, and 
> it may not be cost-effective to add SSH just for NETCONF.
> 

Andy,

Can you clarify why you believe that it should be done in the security
area, rather than having it done - as the other NETCONF transport
documents were produced - in the OPS area with security area advice and
review? 

To be clear, I do not mind an other area taking the pain for
shepherding, quite the opposite, but I do not see what is the clear home
of it in SEC, and I am not sure that taking into account the different
priorities of OPS and SEC, it will get a more efficient processing
there. 

Dan

---

From: Andy Bierman <[email-masked]>
Date: Sun, 29 Jul 2007 06:23:44 -0700

> documents were produced - in the OPS area with security area advice and

  - All of the challenges to producing a standard for this feature
    are security-related, such as the user identity for the session.

  - ISMS has already made progress in this area, and that work
    (done in the security area) needs to be considered, rather than NETCONF
    just reinventing something for itself.

  - Current syslog work is being done in the security area because
    it is (mostly) security-related.

  - The NETCONF community clearly wants to do some new work, but at least
    6 major features are prioritized higher than an additional optional
    transport protocol at this time.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Jul 2007 16:39:07 +0200

See in-line. 

Dan

> Sent: Sunday, July 29, 2007 4:24 PM
> To: Romascanu, Dan (Dan)
> Cc: Martin Bjorklund; [email-masked]
> Subject: Re: [NGO] hum ++
> 
> >> I support standards track publication of the NETCONF over TLS work 
> >> item as an optional transport for NETCONF.  IMO, the more devices 
> >> HTTPS configuration software do not generally have 
> SSH-based CLI or 
> >> XML operator interfaces, and it may not be cost-effective 
> to add SSH 
> >> just for NETCONF.
> >>
> >> I cannot contribute to this document however. IMO, it 
> should be done 
> >> in the security area.
> >>
> >>
> > 
> > 
> > Andy,
> > 
> > documents were produced - in the OPS area with security area advice 
> > and review?
> 

Maybe principal challenges are security-related, but the document is
similar to another three RFCs already issued by NETCONF. 

>     it is (mostly) security-related.

So, to what WG would you submit this work in the Security area? 

The advantage in OPS is that we already do NETCONF related work here,
for SEC it would be something new. 

>     transport protocol at this time.

We did not reach consensus yet on priorities, we just have an initial
proposal that may be modified by the current discussions.

---

From: Andy Bierman <[email-masked]>
Date: Sun, 29 Jul 2007 09:24:47 -0700

> Dan

Which WG should do the work?
Perhaps a BoF, leading to a new WG, like ISMS, would decide that.
In my experience, the overhead of the (well-justified)
security area review and re-write process is a burden
not too be taken lightly.  The work in ISMS must be considered
as well, so the same mechanisms can identify users in any
NM protocol over TLS.

Just because the author seems to have used a previous NETCONF document
as the template for his Internet draft does not mean the work should
be done in the NETCONF WG.  My sense in the SEE BoF was that this
was not something the people in the room wanted to work on for years.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 29 Jul 2007 19:37:34 +0200

On Sun, Jul 29, 2007 at 09:24:47AM -0700, Andy Bierman wrote:

> The work in ISMS must be considered as well, so the same mechanisms
> can identify users in any NM protocol over TLS.

ISMS is not chartered to specify SNMP over TLS and hence ISMS can only
be of limited help here. I agree, however, that NM protocols over TLS
should be using the same mechanisms to identify users.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "David Harrington" <[email-masked]>
Date: Sun, 29 Jul 2007 15:38:17 -0400

Hi,

I don't have a problem with this being done in the security area,
where syslog/tls and isms work is being done. In fact, there is a
great deal of synergy between these work efforts.

The security is similar to rfc2818, the spec for https, and the
syslog/tls draft. The NM security threat models for SNMP and Netconf
are similar, and an snmp/tls draft has also been published.

So I agree that doing this work in the security area would make sense.

I do not think there is a lot of work to be done by a WG on this
draft. I have recommended, and still recommend, this be treated as an
experimental effort, with the burden of driving the process on the
authors of the document, not on a WG. The authors will need to ensure
that there are adequate reviews and possibly implementation work to
show the work is viable. It can be made standards-track later if
desired. An alternative would be to move the effort to the NMRG as a
research effort, which also could be brought to the IETF as a
standards-track proposal later.

dbh

> Sent: Sunday, July 29, 2007 12:25 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 30 Jul 2007 11:45:43 +0200

In-line.

Regards,

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Sunday, July 29, 2007 10:38 PM
> To: 'Andy Bierman'; Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: netconf/tls
> 
> Hi,
> 
> I don't have a problem with this being done in the security 
> area, where syslog/tls and isms work is being done. In fact, 
> there is a great deal of synergy between these work efforts.
> 
> The security is similar to rfc2818, the spec for https, and 
> the syslog/tls draft. The NM security threat models for SNMP 
> and Netconf are similar, and an snmp/tls draft has also been 
> published.
> 

Where in the security area? 

> 
> I do not think there is a lot of work to be done by a WG on 
> this draft. I have recommended, and still recommend, this be 
> treated as an experimental effort, with the burden of driving 
> the process on the authors of the document, not on a WG. The 
> authors will need to ensure that there are adequate reviews 
> and possibly implementation work to show the work is viable. 
> It can be made standards-track later if desired. An 
> alternative would be to move the effort to the NMRG as a 

The question of making the document experimental or standards-track is
orthogonal with where it is hosted. In both cases it needs a WG or RG to
host it, or an AD to sponsor it. The difference between experimental and
standards track is the duration of the IETF Last Call and the threshold
of approval in the IESG review.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Jul 2007 13:07:39 +0200

> Where in the security area?

What is important is that security people do early reviews. I think
this can also be achieved by approaching people and asking for review
and does IMHO not necessarily require a security area WG. Chartering a
security area WG to do a NETCONF over TLS mapping seems overkill to me
(but then it is the ADs who have to care about this not me ;-).

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 30 Jul 2007 13:22:46 +0200

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Monday, July 30, 2007 2:08 PM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; Andy Bierman; [email-masked]
> Subject: Re: [NGO] RE: netconf/tls
> 
> What is important is that security people do early reviews. I 
> think this can also be achieved by approaching people and 
> asking for review and does IMHO not necessarily require a 
> security area WG. Chartering a security area WG to do a 
> NETCONF over TLS mapping seems overkill to me (but then it is 
> the ADs who have to care about this not me ;-).
> 
> /js
> 

I agree that expert review from the security area at an early phase is
the important issue. 

I will approach the security ADs with the request. 

Dan

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 30 Jul 2007 13:55:30 +0200

I'm willing to (co)author the fine-grained locking
draft and review the netconf monitoring and schema advertising drafts.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 30 Jul 2007 05:07:10 -0700

> 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.

Andy

>> 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.
>>
>> 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:
>>>

---

From: "tom.petch" <[email-masked]>
Date: Tue, 31 Jul 2007 11:24:48 +0200

I am happy to contribute to work on netconf/tls.  I do believe that it needs the
ongoing supervision of a security AD.  Security is weird at the best of times
and the value of TLS for authentication is an ongoing debate (at present, on the
TLS list, in the context of GSSAPI).

I do not think that either syslog/tls or https are a satisfactory model.  The
threats to syslog are much weaker and, while https is very widely used, the
manner of its usage would not, IMO, affer acceptable security to the IESG.

Tom Petch

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 30, 2007 1:22 PM
Subject: RE: [NGO] RE: netconf/tls

Dan