Subject: RE: [Isis-wg] Regarding document for best current practices

From: RJ Atkinson <[email-masked]>
Date: Wed, 09 Jan 2002 08:17:33 -0500

At 14:44 08/01/02, Les Ginsberg wrote:
>In my view, what is needed is not a BCP document, but rather a new version
>of RFC 1195. This would not need to supplant existing RFCs describing
>protocol extensions, but it should at a minimum correct inaccuracies and
>obsolete items in 1195, and hopefully go on to define extensions to the
>protocol which have become common practice but have never been documented -
>and have interoperability issues. 

        This is not necessarily a bad thing.  A major question is whether 
someone with a fair amount of implementation experience would have the time 
and inclination to edit such a draft together. 

>It is not a good thing when protocol extensions are made and left purely 
>to word-of-mouth/reverse engineering style documentation.

        Quite so; that historical and problematic practice is precisely why 
this IETF group exists (and why a former O&M AD drove creation of this WG).

>I would love to believe that a meaningful liason between IETF/ISO/ITU
>regarding IS-IS could be achieved, since that would allow all the interested
>communities to participate in the evolution of the protocol - but having
>spent a fair amount of effort trying to make that happen, I am not
>optimistic. 

        Where did this liaison initiative wedge (in your view) ?

        Certainly everyone *could* participate here, so such an effort 
could be undertaken in the IETF provided ITU/ISO didn't object to letting
IETF have formal change control.  Under ITU-T rules, not everyone could
participate equally.  I don't know how ISO rules work these days, so am
not sure how that factors in.

Ran
[email-masked]

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Micah Bartell <[email-masked]>
Date: Wed, 09 Jan 2002 10:47:24 -0600

>         Where did this liaison initiative wedge (in your view) ?

The interest in the ISO is virtually non-existent.  The 2001:10589 draft 
probably saw actual review by 3-4 people within the ISO.  I think almost 
everyone who was involved is already involved with this WG.

>not sure how that factors in.

With IS-IS being protocol neutral, would it be possible to write up an 
informational RFC which contains the protocol framework, but not the CLNS 
specific details?  Implementations going forward would either conform to 
ISO/IEC 10589 or RFC XXXX (or both).

At that point, 1195 can be redrafted if it is felt there is a need as more 
of a TLV definition document.

I just do not know about the politics involved with this.  I can look into 
this with the SC6 Secratariat if there is sufficient interest.  ISO/IEC 
10589 is copyrighted...so it may be as simple as formal permission for the 
IETF to make use of the content in 10589, which could be put to a vote.

/mpb

---

From: Tony Li <[email-masked]>
Date: Wed, 9 Jan 2002 22:54:21 -0800

| With IS-IS being protocol neutral, would it be possible to write up an 
 | informational RFC which contains the protocol framework, but not the CLNS 
 | specific details?  Implementations going forward would either conform to 
 | ISO/IEC 10589 or RFC XXXX (or both).

While that's certainly possible, I would be very concerned about the long
term implications.  The danger of the two versions diverging would be
huge.  [Example: ISO picks up and processes a defect report and issues a
revised draft... but no one remembers to fix the IETF version.]

 | I just do not know about the politics involved with this.  I can look into 
 | this with the SC6 Secratariat if there is sufficient interest.  ISO/IEC 
 | 10589 is copyrighted...so it may be as simple as formal permission for the 
 | IETF to make use of the content in 10589, which could be put to a vote.

We would welcome any way to move forward out of this quagmire.

Let me offer a germ of an idea: As has been pointed out, there is a great
deal of overlap between the actual folks doing the work in both
organizations.  No matter where we host it, it's the same folks, doing the
same thing.  Why then, does it really matter, where the group is hosted?
Why not have just one joint, integrated working group, which reports to two
bodies?  This way, the group has the clear authority to issue definitive
documents.  These documents get published as BOTH ISO standards and RFCs.

I realize that this is probably unprecedented on both sides of the fence,
but it seems only logical to construct a pseudonode adjacency here.  ;-)

Tony

---

From: Micah Bartell <[email-masked]>
Date: Thu, 10 Jan 2002 17:44:19 -0600

>revised draft... but no one remembers to fix the IETF version.]

That is if the ISO can find anyone to integrate a defect report.  However, 
point taken with respect to divergence between the standards.  I think with 
the decline of OSI, this is likely to much more a problem in theory than in 
practice.  The only changes that are foreseeable come through the ISO would 
be for the ITU modifications to provide additional support for multiple 
protocols in SONET.

It may be that if the IETF created a version, the ITU modifications could 
be submitted as an RFC, in addition as Defect Report's against 10589.

>same thing.  Why then, does it really matter, where the group is hosted?

The ISO requires paid membership.  The JTC1/SC6/WG7 is a very small part of 
the ISO, so it is unlikely to obtain much by way of traction in making 
anything unusual happen.  The US is no longer ever a P-Member of the JTC1 SC6.

>bodies?

It is probably easier through voting to get the ISO to let go of the IS-IS 
spec.  I have seen examples where ISO specs no longer exist.  They have 
been removed from circulation and work on the project is officially ended.

>This way, the group has the clear authority to issue definitive

That requires that both organizations agree on the documents.  Many rounds 
of voting if there is disagreement, and potential deadlock if agreement 
can't be reached.

>but it seems only logical to construct a pseudonode adjacency here.  ;-)

When you migrate all of the customers from one router to another, you 
remove the old router from service. :)

/mpb