Re: IAB comments on draft-baker-liaisons-00.txt - Who to communicatewith?

[Stephen J Trowbridge <sjtrowbridge@lucent.com>]

Leslie,
As with my last reply, if we want to address the problem of who
to communicate with in a formal process, we can, but I think it
should be a seperate document.

As I mentioned before, an example of what such a procedure might
look like can be found in ITU-T Recommendation A.4. The A series
of Recommendations can be downloaded for free by anyone (you don't
have to be a member, and it doesn't count against your 3 free
downloads per year per email address) from:
http://www.itu.int/rec/recommendation.asp?type=products&lang=e&parent=T-REC-A
Procedures are given for a communication channel initiated internally
(by ITU-T, in the case of this document) and for a communication channel
requested by the outside organization. One interesting thing you might
want to look at is the table in Annex A of A.4 which lists qualifying
criteria for an external organization (factors like relationship of the
other org's objectives and work to that being dealt with internally,
legal status & membership of the other group, the other group's IPR policy,
etc.).

I am sure that many looking at A.4 would just see it as an example of
ITU-T going overboard in terms of process, but something like this would
certainly address the concerns.

My inclination would be to just keep this in mind as a potential (not
a current) problem, and to not go overboard in IETF in terms of these
kinds of processes unless we see things getting out of hand in terms
of the particular organizations we end up communicating with. If this
becomes a problem, we can look at doing something like an IETF analog
of ITU-T Rec. A.4.
Regards,
Steve

On 8/15/2003 5:06 PM, Scott Bradner wrote:
> I'll agree with those concerns
> 
> ---
>>From leslie@thinkingcat.com  Fri Aug 15 19:01:15 2003
> Date: Fri, 15 Aug 2003 18:59:10 -0400
> From: Leslie Daigle <leslie@thinkingcat.com>
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
> X-Accept-Language: en-us, en
> MIME-Version: 1.0
> To: Scott Bradner <sob@harvard.edu>
> CC: fred@cisco.com, sjtrowbridge@lucent.com, iesg@ietf.org
> Subject: Re: IAB comments on draft-baker-liaisons-00.txt
> References: <200308152254.h7FMsqcA002469@newdev.harvard.edu>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> 
> 
> One really quick reply -- I think it's helpful to note that my
> concerns are taken from the perspective of "a random SDO walking
> up to IETF documentation and determining how to interface with us".
> 
> I.e., while these guidelines might describe what exists today in
> our relationship with the ITU, my concern is that they fit a lot
> of *other* models, too, many of which we would be less happy with.
> It would be, therefore, helpful to tighten the scope.
> 
> The other distinction that I think could be made clearer is: 
> what sort of approach to take when an SDO is giving us information
> about *their* standards (i.e., for which they are authoritative)
> as opposed to offering general technical comment on our developing
> standards.  It is primarily in the latter case that I think the
> proposal, as it stands, could generate a denial of service.
> 
> Leslie.
> 
> Scott Bradner wrote:
> 
>>there are a number of different issues raised - it may be better
>>to not hit them all at once so I'll comment on the ones that seem
>>to need comment one by one
>>
>>
>>
>>>This seems to open the door to suggesting to other SDOs that they
>>>don't need to interact with the IETF the same way as all individual
>>>participants of the IETF -- through I-Ds.
>>
>>
>>I disagree that "all individual participants of the IETF" communicate with 
>>I-Ds
>>
>>fwiw - I see two rather different cases
>>	1/ a note that says 'you might wantto look at X' or
>>	   'just to let you know the X SDO SG 3 is working on that
>>	   topic' or 'if you use value X for varialble Y it will 
>>	   be compatable with what we are doing'
>>
>>	2/ here is a proposal for technology we would like you to 
>>	   consider
>>
>>I do not think that its reasonbable to insist that the other SDOs use
>>I-Ds for #1 - these sorts of things are normally done in the 
>>IETF with messages to mailing lists
>>
>>for #2 the normal way is with I-Ds if the idea is for the WG to
>>do something with the text - but its also not that uncommon to
>>get someone sending a URL to a list and suggesting that the WG
>>folk take a look at this paper by Craig.
>>
>>this particular assertion has been made before (tell them to use I-Ds)
>>because we do
>>	1/ I don't think "we do" for most of the cases this would
>>	   deal with
>>	2/ insisting on I-Ds sounds like an effective to make sure the
>>	   IETF working groups stay uninformed about what others
>>	   (in other SDOs and researchers) are doing
>>
>>note that RFC 3356 (interaction with the ITU) says:
>>3.3.2 ITU-T to IETF
>>
>>   A Study Group or Working Party may send texts of draft new or revised
>>   Recommendations, clearly indicating their status, to the IETF as
>>   contributions in the form of Internet Drafts.  Internet Drafts are
>>   IETF temporary documents that expire six months after being
>>   published.  The Study Group or Working Party must decide that there
>>   is a benefit in forwarding them to the IETF for review, comment and
>>   potential use.  Terms of reference for Rapporteur Group meetings may
>>   authorize Rapporteur Groups to send working documents, in the form of
>>   Internet Drafts, to the IETF.
>>
>>   In these cases, the document editor would be instructed to prepare
>>   the contribution in Internet Draft format (in ASCII and optionally
>>   postscript format as per [RFC2223]) and submit it to the Internet
>>   Draft editor (email internet-drafts@ietf.org).  Alternatively, the
>>   Study Group, Working Party or Rapporteur Group could agree to post
>>   the document on a web site and merely document its existence with a
>>   short Internet Draft that contains a summary and the document URL.
>>   The URL can point to a Word document as long as it is publicly     
>>   available and with the understanding that it will not be eligible for
>>   publication as an RFC in that format.
>>
>>so the intent is not to say that I-Ds are not a good thing, they are just
>>not the only thing
>>
>>Scott
>>
> 
> 
>