Subject: RE: Evaluation: draft-ietf-netconf-ssh-05.txt to Proposed Standar d [I06-051127-0011]

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 17 Mar 2006 13:41:57 -0800

Eliot Lear wrote:
> 
> McDonald, Ira wrote:
> > Netconf is at best a 'niche' protocol at present, because:
> >
> > (a) Netconf currently has no standard data models
> >   
> 
> This has no bearing on the protocol.  We're not going to change ports
> if/when this problem is solved.
> > (b) Netconf currently is intended for use only with routers and
> >     other intermediate network elements
> >   
> 
> So what?
> > (c) Netconf operations have fuzzy semantics, due to the lack of any
> >     standard data models (e.g., "merge this blob with that blob")
> >   
> 
> This is the same as (a).
> 
> > Therefore, Netconf in not plausibly a critical system service.
> >   
> 
> That doesn't follow.  If device config gets shoved around it's a
> critical system service - there are few more critical.

Hi Eliot,

If Netconf is not a _ubiquitous_ general replacement for SNMP
and other legacy configuration protocols for ALL network
elements, then it's not a critical system service - period.

Using IANA-assigned "Well Known Ports" is a political vanity
issue - not a technical issue.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Mar 2006 13:47:26 -0800

Ira,
> elements, then it's not a critical system service - period.
SNMP didn't start as a ubiquitous replacement for anything.  It's a
mistake to make this decision based on popularity.  The question in my
opinion is ONLY a matter of who can bind the port and what impact it can
have.  Now, arguably one could argue that if you get your process
initiation order correct, this isn't a problem.  On the other hand, if a
process can be killed, then the problem recurs.  This to me is the
technical issue.  It's not a political vanity.  If we were talking
about, oh, say, the "talk" or "finger" protocols, I'd feel differently...

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Mar 2006 17:11:16 -0500

This seems to argue that any service that needs to be assigned a port 
number must be using a port number <1024. (After all, if it didn't, 
anyone could grab that port.)
As a matter of widely accepted practice, that is no longer the 
case.  For example, SIP servers (and proxies) use ports above 
1024.  In fact, if you look at the IANA registries, many, many, 
protocols use well known ports above 1024.
I can not see any reason that NetConf is any more special than a lot 
of those protocols.
So why should netconf demand a port less than 1024.

(As far as I can tell, the distinction between <1024 and >1024 ought 
to be removed.  There is nothing the IETF is defining that benefits 
from that distinct.  that abolition is enhanced if we stop trying to 
make special use of <1024 port.  If that were my only reason, or even 
the most important reason, I wouldn't bother sending this.)

Yours,
Joel M. Halpern

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Mar 2006 14:37:28 -0800

Joel,
> the most important reason, I wouldn't bother sending this.)
I think your parenthetical comment is perhaps the one worth discussing. 
I don't think we would care if we were talking about a finger server,
which sits on port 79 or a UNIX talk server, which seemingly on its own
gobbles up more ports than NETCONF.  So far as I can tell, the only
difference is for those operating systems that want to provide a small
amount of protection against non-privileged process access.  Arguably
that's an implementation issue and really ought not be the subject of
standardization.

Given that it exists, when SHOULD something be assigned <1024?

Eliot