Subject: [newtrk] first two meta questions

From: [email-masked] (Scott Bradner)
Date: Mon, 13 Jun 2005 16:09:18 -0400 (EDT)

In reading (& rereading) the IESG comments on the ISD proposal it seems
to me that there is a lack of common understanding on just what an ISD
is for and what one needs to be.

When the ISD idea came up I came (leapt?) to the conclusion that an ISD
would be an ideal way to say, in most cases with little effort, what a
IETF technology "was".   The example I used in my own mind was an ISD
for the standards process (a since discredited idea but it is an easy
way for me to explain what I had in mind when I asked the Johns to
combine their ideas and develop the ISD ID).  I published an ID to show
such an ISD (I just resubmitted the ID, not as a proposal but as a
discussion tool) - draft-bradner-stdproc-isd-01.txt should show up quite
soon

Thus I assumed that when someone (inside or outside of the IETF) asked
me for a pointer to "the IETF standards process" I would respond "look
at the standards process ISD".  That (XML with a text version) document
would list the RFCs that comprise the current IETF standards process and
describe at some level the relationship between them.  That would be
cleaner than saying - "The basic process is described in RFC 2026 with
the organizations involved described in RFC 2028 and the copyright and
patent parts of RFC 2026 replaced by RFCs 3978 and 3979."  - easier for
me to say and easier for the other person to remember (as well as not
relying on my memory of digit strings).  

The equivalent ISD for a technology would list the RFCs that an
implementer must implement of they want to claim to have implemented the
technology along with information on other RFCs that might describe
optional or experimental extensions to the technology and pointers to
informational RFCs that can be read for more information (such as
requirements RFCs).

I also felt that many ISDs could be very easy to produce and maintain
(and I assumed that a working group that wanted to create a new
technology or update an existing one would be responsible for doing the
work so that the load would not fall to the IESG or AD).  In simple
cases, which I think are the majority, an ISD could consist of a
compilation of the relevant standards announcements (which the IESG is
now wanting working groups to do anyway) with a minimum of connective
text.  (draft-bradner-stdproc-isd-01.txt is an example of one of those.)
A pointer to an implementation report (along the lines of what is now
required for advancing to DS status) could be included as well as a
statement of maturity drafted by the WG.  (e.g., "The foobar working
group, based on a review of the implementation report, feels that the
foobar technology described in this ISD may be considered mature and is
ready to be deployed in disruption-sensitive environments.")

Of course, no all of the IETF's technologies can be so easily described
- the tcpm working group has spent a lot of time putting together an
  excellent  "TCP roadmap" (draft-ietf-tcpm-tcp-roadmap-04.txt) which
could be considered a high-end ISD.

I think that ISDs are useful even for very simple technologies, even
ones that are described in a single RFC, because they provide a clean
way to say that its only the one RFC and to have a way to describe the
maturity of the technology.

There are real problems figuring out what should be covered by a single
ISD in a complex technology.  For example SIP - should a SIP ISD also
include things like SIP-T or should that be a separate ISD?  But I think
the way to figure this out is to think about these kinds of cases as we
need to, not as something that must be worked out in all detail before
we can do anything.

I've felt all along that the ISD would be last-called using the normal
IETF process.  An ISD could be last-called by itself if the only change
to the technology was text in the ISD (for example, adding a pointer to
an implementation report or deprecating one or more RFCs) or along with
Internet drafts if there were revised or new ones.

So now I've said what I had in mind for the idea that we have been
calling ISDs.  The John's document is one way to describe the idea and
its implementation in the level of detail that is needed to actually
implement it, Doug Otis's recent ID is another approach that I think
gets to the same basic place. 

But, after describing what I had in mind while the ISD idea was being
described, I'd like to pop up a level and leave the implementation
details aside for a minute and ask the basic meta questions:

1/ Do people think that it would be useful for the IETF to have a meta
way to say what an IETF technology consists of or is the current system
of numbered RFCs sufficient to meet our needs? 

Please answer the question without getting bogged down in the details -
if people do not feel that it's even a good idea to do this we will
never need to worry about the details.  Make the assumption that the
mechanism could be something like the ISD that the Johns and I have been
thinking of or the database that Doug describes or maybe something
different that we come up with later.

2/ What would be your answer to question #1 if such documents might
never be created for very complicated or some historic technologies/
(i.e., are such documents useful if they have less than full coverage)

thanks

Scott
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 13 Jun 2005 15:34:00 -0700

> of numbered RFCs sufficient to meet our needs? 

While much of the information is available in the current system, a
growing effort is needed to discover related documents.  The current
system provides limited usage or inter-operable guidance, as RFC
designators lag usage.

A meta-structure that aggregates RFCs into sets sharing a common
interest would be beneficial.  This could scale down thousands of RFCs
into sets covering just the hundreds of pursuits.  Only those RFCs that
are no longer useful should be excluded from entering into a set.  A set
could be of one RFC.  This would aid discovery.  It would also enable
the aggregation of usage or inter-operable guidance at some later date.

A reference to a set would offer greater stability, and provide a method
to alert implementers of changes that affect them directly.  Security
alerts, inter-operational problems, or deployment advice could be
obtained from a contemporaneous database, directly referenced using the
set identifier.

> (i.e., are such documents useful if they have less than full coverage)

Partial coverage would be less useful of course.  Partial coverage
would require exhausting a set search and then an RFC search to see if
an existing solution was somehow overlooked.  By first focusing on
establishing the organization of all useful RFCs, additional information
could be added later.  

Hopefully just set definitions would keep the initial process simple
enough to allow full coverage.  Much of this work could be facilitated
by way of scripts and then fine-tuned, where just relationships are
established via meta linkages.  Once the sets are established, then
adding information applied to the entire set would abbreviate the total
amount of information added.  To ensure completion, defining the sets
should not rely upon additional information being created as part of
this process.  This additional information can be include at a later
point.

-Doug

.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 Jun 2005 20:46:36 -0400

>of numbered RFCs sufficient to meet our needs?

Yes, such a descriptive tool would be useful.  Even relatively plain 
standards get messy.

>(i.e., are such documents useful if they have less than full coverage)

Yes.  Some cake is better than no cake, and not as good as the whole cake.
We should take what we can get.

Yours,
Joel M. Halpern

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 13 Jun 2005 22:01:26 -0500

> of numbered RFCs sufficient to meet our needs?

Yes, it would be useful to have a way to define an IETF technology. I 
can't imagine that we would design the current system if we were 
starting today (chronologically ordered set of specifications with no 
other structure for the vast majority of standards).

> (i.e., are such documents useful if they have less than full 

ISDs would be most useful for complicated technologies, of course (you 
need a map most when you are most lost). If ISDs are never produced 
for historic technologies, we are prevented from saying, "look for it 
in the ISD series" as the default pointer to anyone who wants to 
implement our specifications, but maybe that's the only bad thing 
about it (people DID manage to implement Telnet without ISDs in the 
first place).

Spencer 

.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jun 2005 23:56:11 -0700

Folks,

>  Yes, such a descriptive tool would be useful.  Even relatively plain

dumb, marketing-type question:  how is an ISD document all that much 
different from an STD document?

Both contain sets of citations of IETF standards.

I'm asking for the elevator pitch, to distinguish this type of doc from 
all other docs.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 14 Jun 2005 06:41:23 -0400

> of numbered RFCs sufficient to meet our needs?

Yes, it would be useful. No, the numbered RFCs are not sufficient.
(that's 2 questions)

> (i.e., are such documents useful if they have less than full coverage)

The same.

.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 14 Jun 2005 08:03:53 -0400

>of numbered RFCs sufficient to meet our needs?

Yes, I think that this would be useful, and no, I don't think that 
numbered RFCs serves this purpose.  I think that this would be best 
implemented as a hyperlinked web site, not as a document series, 
though.

I do not think that it would be useful to mix this meta information 
together with normative information that is required to implement the 
standards (i.e. clarifications and errata), nor do I think that the 
meta information should generally be used as a normative reference in 
other RFCS -- I think that we should continue to use a reference to 
the actual RFC.

>(i.e., are such documents useful if they have less than full coverage)

Personally, I think that the meta information (which may or may not 
be contained in "documents" in any traditional sense) would be _more_ 
useful if it didn't have full coverage of everything that has ever 
been published as a PS, DS or FS.  I think it is important for the 
meta information that  is created to be of consistently high quality 
and current relevance.  IMO, it shouldn't be necessary to sort 
through a lot of chaff (such as autogenerated information about each 
PS document) to find the wheat.

Margaret

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 14 Jun 2005 07:57:51 -0500

Equally dumb marketing-type answer...

> I'm asking for the elevator pitch, to distinguish this type of doc 

STDs, as practiced today, are available for full Internet Standards 
only. This means that any protocol still actively being developed will 
not have a STD until the specification work is complete.

If you want anything like a STD/ISD for any part of SIP, for instance, 
we need ISDs.

Refer to any of the "what the heck is TCP really/what the heck is SMTP 
really?" threads that have appeared here and/or on IETF mailing list 
over the past couple of years for examples of "STDs" that specify how 
NOT to implement a protocol (imagine the Internet suddenly filled with 
STD-compliant TCPs that don't do slow start/congestion avoidance! but 
they would comply with the STD).

Spencer 

.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 14 Jun 2005 10:00:05 -0400

> relying on my memory of digit strings).  

Even with that example, there are cases where one might like to include
some RFCs (e.g. 2418, 3669, 3934 for WG issues) and other cases where
those are not applicable (individual submissions and independent
submissions are obvious counterexamples to the parenthetical example
group above).  There's also the question of whether we're talking about
"standards" or RFCs in general (one of the parenthetical examples above
has Informational status).
 
> I also felt that many ISDs could be very easy to produce and maintain

Perhaps. I suspect that many would be difficult.  Consider the Internet
Message Format.  Aside from STD 11 vs. RFC 2822 and the related issues
of Standard vs. Proposed and obsoletion (already discussed here), there
are a number of other issues:
o At one time, MIME could have been (and was) said to be orthogonal to
  the Internet Message Format.  I do not believe -- from the POV of an
  implementer who wishes to claim to have implemented the technology --
  that that remains true.  MIME is too widely deployed and used, not
  only in user-to-user communications, but in MDNs (RFC 3798) and DSNs
  (RFC 3464) which are themselves important for implementations and
  which are layered on top of MIME (MTSNs, RFC 3886, may become
  similarly important -- or not -- in time).
o In some cases, but arguably not in others, transport of the format
  may have implications.  Possibly reference could be made of transport-
  protocol (POP, SMTP, IMAP, NNTP, MPP, LMTP) ISDs.  If ISDs are
  supposed to indicate obsoleted protocols, then as far as transport
  of the Internet Message Format is concerned, that would include
  mention of MTP (RFCs 780, , 784-786) and FTP through the RFC 765
  version of the specification, but not RFC 959 and later, from which
  Internet Message Format-specific transfer commands were dropped.
  Transport and transported content format are not always easily
  separated; some format syntax requirements relate to transport
  protocol limitations, and some transport protocol extensions are
  related to format characteristics.  Implementers at least need to
  be aware of the intertwined nature of formats and transport protocols.
  That means that transport protocol ISDs may also need to reference
  the format ISD(s); see the chicken vs. egg remarks below.
o There are many extensions to the Internet Message Format, some for
  general use and others related to specific applications of the format.
  Whether these are superfluous, moderately interesting, or critically
  important to an implementer depends on the details of what the
  implementer is doing; an implementer working in a specific problem
  domain may find some extensions critically important, others
  irrelevant.  An implementer working on a general-purpose parser
  needs to be aware of all of them.
o Understanding any or all of the RFCS may require understanding
  several relevant RFCs describing the standards process, the
  "not all RFCS are standards" RFC, BCP 14 keywords and the
  implications or their (proper) use, various glossaries (e.g.
  FYIs 18 & 36), etc. (e.g. RFCs 1958, 2277, 3117, 3536, 3692,
  3935).
o Note that some RFCs related by one or more of the above considerations
  may use different, sometimes conflicting, terminology or viewpoints.
  In addition to the terminology glossaries, implementers may need to
  understand RFCs such as 3930.
o Some implementers may need to understand the use of underlying
  protocols; in the case of the Internet Message Format, RFC 3467
  and other DNS-related RFCs are applicable.
o Some implementers working on applications layered on top of the
  Message Format or its transport protocols (e.g. VPIM) will need
  to be familiar with additional application-specific RFCs.  It may
  be possible for an application-specific ISD to refer to the one
  for the Message Format -- but in this case and in the case mentioned
  above for references to transport protocol ISDs, there is the
  chicken vs. egg problem; one cannot refer to an ISD that doesn't
  yet exist.
o Some implementers need to be more or less concerned about gateway
  issues (e.g. RFCs 976, 2156, 2157).

> ready to be deployed in disruption-sensitive environments.")

What happens when the foobar group believes that, but security experts
believe otherwise (see the current discussions on the IETF discussion
list regarding CRAM-MD5 and a Last Call on a proposal for BCP)?

> need to, not as something that must be worked out in all detail before

Perhaps; I've outlined a few issues relevant to one technology above.
I think that at minimum we need to think about the chicken-and-egg
issue and how cross-references to other ISDS would work.
 
> of numbered RFCs sufficient to meet our needs? 

For full standards, we already have the std-index, which (e.g.) says that
STD 3 consists of RFCS 1122 & 1123, STD 5 consists of RFCs 791, 792,
919, 922, 950, & 1112, etc.  We also have the periodic Official Internet
Protocol Standards RFC (STD 1, currently RFC 3700).

One recurring theme in discussions here is use of some document reference
in RFPs and similar contractual documents.  RFCs are guaranteed to be
unchanging; STDs do change as the underlying set of RFCs change, and ISDs
may do likewise.  Somebody recently noted that references to STDs in
such documents are rare; that's not difficult to understand -- one may
understandably be hesitant to reference a document whose contents may
unexpectedly and unpredictably change (ISD version indications address
that issue).

An ISD-like series that is like the STD series w.r.t. grouping RFCs
but with version indication would be a useful extension.
 
> (i.e., are such documents useful if they have less than full coverage)

Basically the same, but dependent to some extent on if/how issues of
cross-references and the chicken-and-egg situation are resolved.

---------

I propose that one way to resolve the issue of cross-references is to
explicitly permit cycles in references (e.g. Internet Message Format
(IMF) ISD could reference MIME and transport protocol ISDs, MIME ISD
could reference IMF and transport ISDs, transport protocol ISDs could
reference IMF and MIME ISDs).  That has implications (obviously,
dependencies could not be represented as a directed acyclic graph, as
there would be cycles).

I don't have a good solution for the chicken-and-egg problem; it seems
that some substantial set of ISDs would have to be produced together.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Jun 2005 16:33:56 +0200

What he said.

(And if it isn't obvious, my AD hat is firmly off when I
comment on the issues in this WG. I'll tell you when I need
to put it on).

    Brian

.

---

From: John C Klensin <[email-masked]>
Date: Tue, 14 Jun 2005 11:27:33 -0400

--On Monday, June 13, 2005 11:56 PM -0700 Dave Crocker 
<[email-masked]> wrote:

> Folks,
>
>>  Yes, such a descriptive tool would be useful.  Even
>>  relatively plain standards get messy.
>
>
> dumb, marketing-type question:  how is an ISD document all
> that much  different from an STD document?
>

Um, whoops...   Except, perhaps, for coming into being at 
Proposed and hence trying to deal with the pragmatics of how few 
documents get to full Standard, an ISD document might be 
identical to an STD   document, if there were any such thing as 
an STD document. But there is no such thing as a STD document, 
there are just numbers in an index that lists one or more RFCs 
associated with that STD number.  There is no information about 
how those documents relate, no information about how other, 
non-full-standard things coming down the road might interact 
with them, and so on.

> I'm asking for the elevator pitch, to distinguish this type of
> doc from  all other docs.

I think the above does not require the elevator to make it up 
more than one floor.

   john

.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jun 2005 08:55:01 -0700

>  only.

so, if we changed the definition of STD to include any document on the 
standards track or labeled as BCP, we'd have an ISD?

  d/
  ---
  Dave Crocker

.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jun 2005 10:40:43 -0700

>  But there is no such thing as a STD document,

OK.  This is certainly true and i believe represents a significant deficiency.

For purposes of discussion, let me suggest a somewhat modified slant on this:

1) Make STD open to any standards track document, not just those that have 
attained full standard.  This is a discrete step that we ought to have done 
years ago.

and:

The IETF has come to use a number of common paradigms for documents, such as 
requirements, protocol and some others.  My own view of specifications is that 
it is good to distinguish between components and services.  Most IETF 
specifications are really for components. In effect, an STD set of documents 
defines a "service".  What we rarely have is anything that describes the set. 

2) So an Internet Service Description (ISD) could be a document that 
provides detail about the integration and operation of component 
specifications and practises into a coherent service.  The xml approach 
that has been discussed sounds pretty useful for this.  The document 
could be a BCP that is added to an STD set.

  d/
  ---
  Dave Crocker

.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 14 Jun 2005 11:05:10 -0700

Just in brainstorming mode....

I'm trying to optimize:
   - Better information to the global community about the
     actual state of IETF specifications
   - Removing bottlenecks in the IETF process
      (and, in particular, IESG approval steps)

With that in mind, 

The current ideas for an "ISD" to me look more like
"working group charter" documents than like a "standards
track IESG approved document".

Instead of instituting yet another series of formal
documents that get last called and IESG reviewed and
voted on, consider having "sub-areas", with chairs
and charters. There might be a SIP sub-area and a
HTTP sub-area and a URI sub area.

Sub-areas would have charters (that would describe
the general area), that would contain pointers to
documents, working groups, interoperability reports,
intellectual property statements. Sub-areas would
also have chairs and mailing lists.

Updates to the sub-area pointers to documents,
interoperability reports, IPR statements, etc.
would not require IESG approval. (The IESG might
only get involved in the case of disputes.) When
an interoperability statement is made, the
sub-area chair(s) could approve its inclusion
in the sub-area web page.

Sub-areas might also have overview documents and
overview document authors, which would be
"standards track"; the sub-area chairs would
be encouraged to find authors to write such documents
and get IESG approval for them. This would be
useful, but not necessary.

Once we have this structure, and a way
of asserting interoperability and deployment, we 
might consider eliminating "draft standard", or,
perhaps, merging "proposed standard" and
"draft standard" into one status, "standards track",
for RFCs. We could keep "full standard".

Justification:

Avoid having the IESG try to make assertions for
which they don't have first-hand information
(about interoperability). Push the statements
about interoperability into the community.

For many of the areas I'm familiar with, there exist
already mailing lists that cover a general
"sub-area" -- often the mailing list for a 
now-closed working group.

This proposal makes it clear who will do the work,
and how it will get done, which is something I
couldn't figure out with the ISD proposals.

.

---

From: mcr <[email-masked]>
Date: Tue, 14 Jun 2005 15:17:00 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:
    Dave> dumb, marketing-type question: how is an ISD document all that
    Dave> much different from an STD document?

    Dave> Both contain sets of citations of IETF standards.

    Dave> I'm asking for the elevator pitch, to distinguish this type of
    Dave> doc from all other docs.

  An ISD is a collection of documents, some of which are STD.
  The ISD is clear about which documents/features are critical parts of
the spec, and which are experimental.

====
  
  In the IPsec space, we would have significantly benefitted from having
a "site-to-site VPN" ISD, and a "remote-access VPN" ISD, and a
"host-security ISD".
  
- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
]                    I'm a dad: http://www.sandelman.ca/lrmr/                 [
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jun 2005 12:19:42 -0700

>  a "site-to-site VPN" ISD, and a "remote-access VPN" ISD, and a

Hmmm. Interesting.

Methinks this discussion would benefit from some concrete exemplars of candidate 
ISDs...

  d/
  ---
  Dave Crocker

.

---

From: mcr <[email-masked]>
Date: Tue, 14 Jun 2005 15:37:23 -0400

-----BEGIN PGP SIGNED MESSAGE-----

John, 

We have a series of RFCs:
   1122 Requirements for Internet Hosts - Communication Layers. 
	(STD0003)
   1123 Requirements for Internet Hosts - Application and Support. 
	(STD0003)
   1127 Perspective on the Host Requirements RFCs. 
   1349 Type of Service in the Internet Protocol Suite.		(PS)
   2181 Clarifications to the DNS Specification.		(PS)
	-> RFC2535,RFC4033,RFC4034,RFC4035
	(curiously, not RFC3445)
	[and it goes on...]

that someone defines what it means to be "online".
We don't update documents like 1122/1123 very often, because it is hard.
1123 is particularly, quite an omnibus document.

My feeling is that we would not produce a simple ISD to replace these
documents, but rather somewhere between 2 and 5 ISDs.

- -- 

.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 14 Jun 2005 15:52:31 -0400

>a "site-to-site VPN" ISD, and a "remote-access VPN" ISD, and a

Perhaps.  However, I am curious if the IPsec WG would have been bogged 
down with discussions on what goes into the ISDs and with what 
classification, that is, in the same vein as MUST/SHOULD/MAY.  
Interpreting the keywords (or applicability) at the ISD level, and again 
at the RFC level and the combination of requirements for "compliance" in 
my view would create a nightmare both during ISD publication stage as 
well as later when others are interpreting the ISD+RFCs.

 From what I know of the IPsec world, documents on remote-access etc., 
were written within industry consortia.  (BTW, this type of practice is 
also found in the example of IEEE 802.11 specs and WiFi Alliance, 802.16 
and WiMAX, and so forth).

I guess what I am saying is that we in the IETF should probably focus on 
RFC production (we are good at it and a lot of other SDOs, e.g., IEEE, 
3GPP/2, OMA use them and actually ask for new ones to be produced :-)), 
and let others (other SDOs or whoever) put them together in whatever way 
they want.  If a specific RFC or protocol needs certain behaviors from 
other RFCs/protocols, well the RFC should say so without relying on 
another document to do it.  If a roadmap is required, I guess we can do 
that too (Informational).

My 2 cents.

regards,
Lakshminath

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.2 (GNU/Linux)
>Comment: Finger me for keys
>
>iQCVAwUBQq8tKIqHRg3pndX9AQHaugQAkmJHJZ+DSpBI1a5LzGEW7VrlUZff6bYT
>7kMd1QyFQLvtdCoAIKyHsNpsOSViwhrfQvJQfdAEf3II0nkaaWNEZaRfxPbbi1g2
>c04V1nRRGQqNwPkHCQT0b4M1p2lCyiPjj3duoBAG2OGmJZ2HE6Yn9MVWQcdsXVsE
>AKJfJhWQTuE=
>=3IYC
>-----END PGP SIGNATURE-----
>.
.

---

From: mcr <[email-masked]>
Date: Tue, 14 Jun 2005 16:01:56 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Lakshminath" == Lakshminath Dondeti <[email-masked]> writes:
    Lakshminath> Perhaps.  However, I am curious if the IPsec WG would
    Lakshminath> have been bogged down with discussions on what goes
    Lakshminath> into the ISDs and with what classification, that is, in
    Lakshminath> the same vein as MUST/SHOULD/MAY.  Interpreting the
    Lakshminath> keywords (or applicability) at the ISD level, and again
    Lakshminath> at the RFC level and the combination of requirements
    Lakshminath> for "compliance" in my view would create a nightmare
    Lakshminath> both during ISD publication stage as well as later when
    Lakshminath> others are interpreting the ISD+RFCs.

  Well, there have been 2 or 3 attempts to create a VPN WG, later
turning into L2VPN and L3VPN.

  In many cases, these WGs might have produced an ISD rather than a
document.  

    Lakshminath>  From what I know of the IPsec world, documents on
    Lakshminath> remote-access etc., were written within industry
    Lakshminath> consortia.  (BTW, this type of practice is also found

  Some of them were, and they are poorly reviewed, have dubious security
profiles, and are often not well referenced in RFPs or marketing literature.
 
    Lakshminath> I guess what I am saying is that we in the IETF should
    Lakshminath> probably focus on RFC production (we are good at it and

  The IETF is about producing standards. Standards are not measured in
quantity of RFCs, and perhaps not even in quality of RFCs.

- --

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jun 2005 13:23:57 -0700

>  classification, that is, in the same vein as MUST/SHOULD/MAY.  

It seems to me that a document of this type is useful, independent of whether 
there is a formal way to plug it into our indexing system.

If in fact one cannot be generated because it gets bogged down in debates, 
that's a rather useful bit of knowledge to have, prior to creation of an 
institutional framework for using such documents.

  d/
  ---
  Dave Crocker

.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 14 Jun 2005 17:15:42 -0400

Hi,

I don't want to side-track the discussion, but I'll respond to some of 
your comments to point out that ISDs cannot fix problems that we might 
expect them to fix.

>profiles, and are often not well referenced in RFPs or marketing literature.
ISDs cannot fix this type of problems.  Various bodies will pick and 
choose things and that results in questionable designs and so forth.  
There is very little the IETF can do about that.  We can produce more 
RFCs or newer types of documents (ISDs), but others can very well ignore 
(or interpret loosely) them as they do with the MUSTs/SHOULDs, 
especially the SHOULDs, in the RFCs. 

Looking at the newtrk charter --- the part about updating 2026 and plans 
to offer guidance on updating parts of documents --- I was hoping things 
like SHOULD etc., can be clarified better.  To give a concrete example, 
RFC 3711 SRTP goes to great lengths to explain a SHOULD on strong 
integrity protection.  I can't say that about many "SHOULDs" in many 
other RFCs, and that leaves different people, SDOs, industry groups to 
interpret the RFC differently.

Another example of change that I like is from the new IPsec and IKE I-Ds 
and how they separate the crypto algorithms into different documents, 
which allows easy updates to simpler documents without "opening" up the 
core IPsec drafts.  Once again, done right, everyone will know, by the 
numbers issued what the document grouping is, for instance the 2401 to 
2409 "series."  I wish that is done in all other cases too.

>quantity of RFCs, and perhaps not even in quality of RFCs.
I guess for many, an RFC is synonymous with the IETF.  A lot of SDOs 
produce standards :-), only the IETF produces RFCs.  Speaking to the 
quality of RFCs, I guess I am saying somewhat indirectly that ISDs will 
only take away time from the critically small pool of quality editors 
writing the RFCs.  Super documents such as the ISDs, in my view, are a 
waste of time for the IETF contributors.

regards,
Lakshminath

>iQCVAwUBQq83soqHRg3pndX9AQHWvAP/YBLt8pzq/B4mWCAzjdD9ZEn1vFxhWkzb
>8X1CLqHwvvKGWPrffLsCeWGm5grHqfSjStQO2k6fS4rHQ5eLhHN66bQ82zYFdr3J
>zgJcVRUKwxjdpuWP8A8taNdNop1J0+EoccqsVBPzjjUQfGez1p38KyitmOS66kno
>usoKdfCtwaA=
>=Bx24
.

---

From: mcr <[email-masked]>
Date: Tue, 14 Jun 2005 17:42:25 -0400

-----BEGIN PGP SIGNED MESSAGE-----

    >> Some of them were, and they are poorly reviewed, have dubious
    >> security profiles, and are often not well referenced in RFPs or
    >> marketing literature.

    Lakshminath> ISDs cannot fix this type of problems.  Various bodies
    Lakshminath> will pick and choose things and that results in

  You missed the point.

  Your point was that these efforts were done elsewhere.

  That's not because the other bodies were appropriate. It was because
those bodies did not impose as large a hindrance to doing stupid things
as the IETF. 

  Part of that hindrance is intentional, but a lot of it is not. The
hindrance is simply bureaucracy. 

  I pushed for a long time for multiple profiles of IPsec --- but it was
simply too much work. We didn't have the tools to provide for it. Had we
had an ISD, the work may well have occured within the IETF.

  I would claim that the work of the IPsec WG would also have been
faster --- because when one person's requirements mandate feature X,
while a second person's requirements mandate "not feature X" we would
have have spent three weeks on this.
  We would have recognized that different profiles were needed, and that
the different ISDs may have well mandated which pieces are
MUST/SHOULD/etc.

  Frankly, the IPsec WG as constructed/evolved was always a bit of a
mistake.  I would like to think that we would never charter a group like
that today. It would have very specific goals ("a single profile"). 

  If I could do it again, I would have many *more* *shorter*
documents. They would have advanced far faster, and we'd let ISD deal
with obsoleting bad ideas.

- --

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 14 Jun 2005 18:13:16 -0400

Hi,

Hope the title isn't too controversial.  I took the liberty to change it 
so I don't hijack the "meta questions" thread.

At the risk of missing the point again, I believe

* We in the IETF can never do all other SDOs' and industry consortia's 
work because 1) "we" don't have the time, 2) others aren't going to wait 
in all cases, and put up with the "hindrance."  Once an RFC is out, it 
is out of IETF's control, whether there are ISDs or not.

* Much of what you proposed below (e.g., Profiles) can be done today 
within the RFC framework.  There were a few corner things ("letting ISDs 
deal with obsoleting bad ideas") that may be difficult, but still doable.

I apologize if I seem to be oversimplifying matters.  (However, I feel 
the ISD framework is also doing that --- oversimplifying --- at the moment).

I do agree with your idea of chartering WGs with limited scope (it will 
help if the BoF process isn't so scary to people like me) and producing 
documents of limited scope.  I wish newtrk proposed something like 
that.  To illustrate, the IKEv2 I-D as written today is in someways 
helpful (I was excited at first that we will have one place to go for 
IPsec key management): having the remote access stuff, NAT traversal and 
all the goodies in one document offers easier access, but OTOH makes it 
very difficult to parse for compliance of any given (especially limited) 
use case.

thanks,
Lakshminath

mcr wrote:

>iQCVAwUBQq9PNoqHRg3pndX9AQFgUQP8DUCoCM+qGE7eDrhleRdLJM9n4yLkDUx/
>qM8bgcoPoHp6/Rv5OpmJPYU1s0Ndi5f1UxsF1mExiT9FeUnclOxKTDabQSuhjAPK
>wEgCP1MeoZ/xFRsq5OPYKHnN7t+z/3d30+k77/ABWj1SwhWAsU9hmy4DFbFvTc5m
>cjMqf5B7ef0=
>=BPcj
.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Jun 2005 19:08:49 +0200

> OK.  This is certainly true and i believe represents a significant deficiency.

One other thing - the STD "groupings", as far as I know,
are a best effort choice by the RFC Editor rather than a grouping
reached by any kind of IETF consensus process. That may not have
been a bug when the STD designation was invented, but it
seems to be a bug now.

    Brian

.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Jun 2005 19:14:38 +0200

> -----BEGIN PGP SIGNED MESSAGE-----
...
> had an ISD, the work may well have occured within the IETF.

Can you explain why such profiles couldn't be published as BCPs?

    Brian

.