Subject: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing

From: "David Oran" <[email-masked]>
Date: Thu, 7 Sep 2000 16:23:02 -0400

Copying the WG...

-----Original Message-----
From: Henk Smit [mailto:[email-masked]]
Sent: Thursday, September 07, 2000 3:50 PM
To: David Oran
Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing

> For those of you who hate MSWORD, I append the text at the end of the
> message text as well.

  Thank you, I appreciate it !
 Pretty weird that a standards body like ISO is using a proprietary
 files format. ;-)

> Are there other drafts they should fold it? If so, please craft a
> response and I'll get it to them.

  draft-ietf-isis-dyname-02.txt is not a draft anymore.
 It is now an RFC: RFC2763.

  I have just submitted a new version of draft-ietf-isis-traffic-01.txt,
 draft-ietf-isis-traffic-02.txt. It might be a while before it becomes
 an RFC.

  And what about RFC1195 itself ? There is no mention that this RFC
 will be incorporated ?

  If RFC1195 is incorporated, there is one more ISIS draft that I would
 like to see added. Tony Li, Tony Prziegynda and myself are also authors
 of a draft that is related. draft-ietf-isis-domain-wide-02.txt. It is
 slated to be an RFC pretty soon, just waiting for the RFC editor to
 process it. If 10589 is including IP specific stuff, I think this one
 should be incorporated too.

    Henk.

> -----Original Message-----
> From: Matthew Deane [mailto:[email-masked]]
> Sent: Thursday, September 07, 2000 11:35 AM
> To: [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'
> Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee'
> Subject: JTC 1/SC 6 Liaison Statement on Routeing
>
>
> > Dear IETF Directors,
> >
> > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the
following
> > document is forwarded to IETF Routeing and Transport Area Directors
> for
> > consideration:
> >
> > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd
> version)
> >
> >
> > Please do not hesitate to contact me should you have any questions.
> >
> > Sincerely,
> >
> > Matt Deane
> > JTC 1/SC 6 Secretariat
> >
> >  <<06n1618.rtf>>
>
>
> 									SC 6 N 11618
>
> Title: Liaison Report to the IETF Routing Area Director on 2nd CD for
> ISO/IEC 10589 (IS-IS Routing)
>
> Source: ISO/IEC JTC1/SC6
>
> ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for
ISO10589.
> SC6 intends to use this new version 2 as the base for adding the
> enhancements which have been requested by the IETF to optimise the use
> of ISO 10589 for Internet routing solutions.  The IETF IS-IS WG
convenor
> originally identified  Internet Drafts:
<draft-ietf-isis-dyname-02.txt>
> and <draft-ietf-isis-traffic-01.txt> as the source documents which
> specify these enhancements.   SC6 invites the IETF to confirm that the
> above Internet Drafts are the correct references and to inform SC6 if
> there are additional IETF documents which refer to any other
> requirements for  IS-IS Routing enhancements.
>
>  SC6 would like to interact with the IETF on clarifying the detailed
> requirements in the hope that it may be possible to  introduce them
> during the editing cycle for version 2 of the standard.   To this end,
> we would like the Routing Area Directors to arrange an IS-IS BOF at
the
> San Diego IETF meeting to discuss these requirements and how they can
be
> incorporated into the new version of  ISO 10586.
>
>  SC6 will post an initial draft version of the new base document as an
> Internet Draft in August 2000 but this will not contain the changes
> requested by the IETF.  A ballot closure date of February 2001 has
been
> set for the 2nd CD Ballot to allow incorporation of final input on the
> Internet requirements if they can be agreed at the December 2000 IETF
> meeting.
>
> For information, the current instructions to the editor are that he
> should use ISO/IEC 10589:1992 as a base for editing, and shall apply
the
> minimum textual changes mandated by the following TCs and DRs:
>
>    ISO/IEC 10589:1992/Cor.1:1993
>    ISO/IEC 10589:1992/Cor.2:1996
>    ISO/IEC 10589:1992/Cor.3:1996
>    ISO/IEC 10589:1992/Amd 1:1996
>    6N10323 - Defect Reports 7-26
>    6N10659 - Defect Reports 27-34
>    6N10733 - Technical Corrigendum 4
>    The editor will also apply the minimal changes necessary to resolve
> additional Defect Reports 35-44.
>
> If SC6 and the IETF are unable to resolve the required changes, the
> Editor will add a temporary note to the cover page and the scope
clause
> stating that:  “ ISO 10589 does not currently include the extensions
> originally requested by the IETF in Internet Drafts:
> <draft-ietf-isis-dyname-02.txt> and <draft-ietf-isis-traffic-01.txt>.
> National Body and Liaison organization comments are invited to comment
> on the best way to progress these extensions.”
>
> ------=_NextPart_000_018E_01C018C0.F5C6AE40
> Content-Type: application/msword;
> 	name="06n1618.rtf"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: attachment;
> 	filename="06n1618.rtf"
>
> {\rtf1\ansi\ansicpg1252\uc1 =
>
\deff0\deflang1033\deflangfe1033{\fonttbl{\f0\froman\fcharset0\fprq2{\*\
p=
> anose 02020603050405020304}Times New Roman{\*\falt CG =
> Times};}{\f2\fmodern\fcharset0\fprq1{\*\panose =
> 02070309020205020404}Courier New;}}
>
{\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue25
5=
;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red25
5=
\green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\gree
n=
> 128\blue128;\red0\green128\blue0;
>
\red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red1
2=
8\green128\blue128;\red192\green192\blue192;}{\stylesheet{\widctlpar\adj
u=
> stright \fs20\cgrid \snext0 Normal;}{\*\cs10 \additive Default
Paragraph =
> Font;}{\s15\nowidctlpar
\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7672\tx8631\tx959
0=
> \adjustright \f2\fs20 \sbasedon0 \snext15 Preformatted;}}{\info{\title
=
> Ethan Frome}{\author EW/LN/CB}{\keywords Ethan}{\operator Matthew =
> Deane}{\creatim\yr2000\mo6\dy9\hr18\min52}
>
{\revtim\yr2000\mo6\dy16\hr14\min3}{\version3}{\edmins1}{\nofpages2}{\no
f=
> words533}{\nofchars3040}{\*\company Lucent =
> Technologies}{\nofcharsws3733}{\vern89}}
>
\widowctrl\ftnbj\aenddoc\noxlattoyen\expshrtn\noultrlspc\dntblnsbdb\nosp
a=
ceforul\hyphcaps0\formshade\viewkind4\viewscale100\pgbrdrhead\pgbrdrfoot
=
> \fet0\sectd \linex0\endnhere\sectdefaultcl =
> {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}}
> {\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta =
> .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta =
> .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta =
> )}}{\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta
=
> )}}
> {\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta =
> )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta
=
> )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb
(}{\pntxta =
> )}}{\*\pnseclvl9
> \pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain
=
\s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7
6=
> 72\tx8631\adjustright \f2\fs20 {\tab \tab \tab }{
> Telecommunications and Information
=20
> \par Exchange Between Systems
=
>  =20
> \par=20
> \par=20
> \par ISO/IEC JTC 1/SC06 N 11618             =20
> \par=20
> \par DATE:  2000-06-16    =20
> \par=20
> \par REPLACES                                    =20
> \par=20
> \par DOC TYPE:
> \par Outgoing Liaison Statement
=20
> \par=20
> \par TITLE:
> \par Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version)
=
>  =20
> \par=20
> \par SOURCE:
> \par SC 6/WG 7 Convener
=
>  =20
> \par=20
> \par PROJECT:                  =20
> \par=20
> \par STATUS:
> \par Per SC 6 Prague Resolution 6.7.7, this document is forwarded to =
> IETF =20
> \par for consideration.
=
>  =20
> \par=20
> \par ACTION ID:  ACT=20
> \par=20
> \par DUE DATE:           =20
> \par=20
> \par DISTRIBUTION:  P & L Members; SC Chair; WG Conveners and =
> Secretaries      =20
> \par=20
> \par=20
> \par MEDIUM:  =20
> \par=20
> \par DISKETTE NO.:           =20
> \par=20
> \par NO. OF PAGES:  1        =20
> \par=20
> \par=20
> \par ISO/IEC JTC 1/SC 6 Secretariat
=
>  =20
> \par ANSI, 11 W. 42nd Street, New York, NY 10036, USA
=
>  =20
> \par }\pard =
\s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7
6=
> 72\tx8631\adjustright {Tel:  +1 212 642 4992;  Fax:  +1 212 84}{0
2298;  =
> E-mail:               [email-masked]}{\tab \tab \tab \tab \tab \tab
=
> \tab }{\b\fs28=20
> \par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\b\fs28 \page=20
> \par \tab \tab \tab \tab \tab \tab \tab \tab \tab SC 6 N 11618
> \par }{
> \par }{\b Title: Liaison Report to the IETF Routing Area Director on =
> 2}{\b\super nd}{\b  CD for ISO/IEC 10589 (IS-IS Routing)
> \par=20
> \par Source: ISO/IEC JTC1/SC6
> \par }{
> \par ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for =
> ISO10589.   SC6 intends to use this new version 2 as the base for
adding =
> the enhancements which have been requested by the IETF=20
> to optimise the use of ISO 10589 for Internet routing solutions.  The
=
> IETF IS-IS WG convenor originally identified  Internet Drafts: =
> <draft-ietf-isis-dyname-02.txt> and <draft-ietf-isis-traffic-01.txt>
as =
> the source documents which specify these enhanceme
> nts.   SC6 invites the IETF to confirm that the above Internet Drafts
=
> are the correct references and to inform SC6 if there are additional =
> IETF documents which refer to any other requirements for  IS-IS
Routing =
> enhancements.
> \par=20
> \par  SC6 would like to interact wit
> h the IETF on clarifying the detailed requirements in the hope that it
=
> may be possible to  introduce them during the editing cycle for
version =
> 2 of the standard.   To this end, we would like the Routing Area =
> Directors to arrange an IS-IS BOF at the San Di
> ego IETF meeting to discuss these requirements and how they can be =
> incorporated into the new version of  ISO 10586.
> \par=20
> \par  SC6 will post an initial draft version of the new base document
as =
> an Internet Draft in August 2000 but this will not contain the changes
r
> equested by the IETF.  A ballot closure date of February 2001 has been
=
> set for the 2nd CD Ballot to allow incorporation of final input on the
=
> Internet requirements if they can be agreed at the December 2000 IETF
=
> meeting.=20
> \par=20
> \par For information, the current instructions to the editor are that
he =
> should use ISO/IEC 10589:1992 as a base for editing, and shall apply
the =
> minimum textual changes mandated by the following TCs and DRs:
> \par=20
> \par    ISO/IEC 10589:1992/Cor.1:1993
> \par    ISO/IEC 10589:1992/Cor.2:1996
> \par    ISO/IEC 10589:1992/Cor.3:1996
> \par    ISO/IEC 10589:1992/Amd 1:1996
> \par    6N10323 - Defect Reports 7-26
> \par    6N10659 - Defect Reports 27-34
> \par    6N10733 - Technical Corrigendum 4
> \par    The editor will also apply the minimal changes necessary to =
> resolve additional Defect Reports 35-44.
> \par=20
> \par If SC6 and the IETF are unable to resolve the required changes,
the =
> Editor will add a temporary note to the cover page and the scope
clause =
> stating that:  \ldblquote=20
>  ISO 10589 does not currently include the extensions originally =
> requested by the IETF in Internet D
> rafts: <draft-ietf-isis-dyname-02.txt> and =
> <draft-ietf-isis-traffic-01.txt>.   National Body and Liaison =
> organization comments are invited to comment on the best way to
progress =
> these extensions.\rdblquote=20
> \par=20
> \par=20
> \par }}
> ------=_NextPart_000_018E_01C018C0.F5C6AE40--
>
>
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://external.juniper.net/mailman/listinfo/isis-wg
>

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

---

From: Micah Bartell <[email-masked]>
Date: Thu, 07 Sep 2000 16:57:25 -0500

Folks,

I will say that the only documents that I integrated into the ISO 10589 2nd edition were those specified in the "Instructions" from the ISO meeting in Prague.  The changes consist of the following documents:

Regarding the changes proposed for DR 35-44, the SIF recommendation was used in place of these DRs.

Nothing IP specific was added to ISO 10589.  The question that the ISO is presenting here to the IETF as I understand it is: 

What does the IETF recommend as the best method moving forward to handle changes to the ISO spec by the IETF and how best should the IP specific information be handled?

The ISO world does not seem intent upon making great sweeping changes to the spec, to the best of my knowledge and most new work is being handled within the IETF.

I think it would be wise to develop a method for dealing with all IETF changes before setting the precedent of integrating ANY of the IETF ID's or RFC's directly into the spec.  That document is already getting unwieldly in Word and if it is going to be accepting another 100 pages of material, it will very likely need to be restructured.

The question of whether the ISO wishes to continue to maintain this spec also needs to be asked.  If not, it may be possible to publish the ISO 10589 as a standards track RFC.  This would likely require some modification to the structure of the document.  ( Does an RFC really need 30 pages of complex conformance tables? )  Also the ISO 10589 spec is not friendly to a purely text based representation.

These are just some of my thoughts on the matter.  While, I am the current editor for the document, I am not presenting these suggestions as a "representative" of the ISO, or stating this to be their official position.

I will investigate further making available the PDF version that I have of the 2nd Edition.  This is pending a response from ANSI.

/mpb

---

From: Henk Smit <[email-masked]>
Date: Fri, 8 Sep 2000 00:23:44 +0200 (MEST)

> What does the IETF recommend as the best method moving forward to
> handle changes to the ISO spec by the IETF and how best should the IP
> specific information be handled?

  Personally I would be in favor of combining all ISO documents and IETF
 RFCs into one, and then splitting it up in three separate documents.

  *) one document that specifies the core of ISIS. How to set up
     adjacencies, what an LSP looks like, what TLVs are, what areas
     are to ISIS, how to run the SPF itself, etc.
  *) one document that specifies all TLVs and algorithms related
     to routing of iso8473 (aka CLNP)
  *) one document that specifies all TLVs and algorithms related
     to routing of IP

  I think especially splitting the core of IS-IS from iso8473 related
 details will make the protocol much more understandable.

  Just my 2 cents, I guess it will never happen ... :-(

         Henk.