Subject: [I2nsf] Mirja Kühlewind's Discuss on draft-ietf-i2nsf-problem-and-use-cases-12: (with DISCUSS and COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 11 Apr 2017 11:26:06 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-i2nsf-problem-and-use-cases-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document should be informational. I don't see any reason that this
document must be cited normatively by all following document of this wg
(as indicated in the shepherd write-up) and even if so that does not
justify publication as Standards track if the information in the document
is only informational.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As soon as my discuss is resolved I will change to 'Abstain' as I don't
see value in the publication of this document. I can see that this
document was useful for discussion in the working group but I don't know
why it needs to be published as RFC. Also there is quite some redundancy
everywhere in the document aa well as between the problem statement and
use case part. Spelling out requirements for the protocol design based on
the analysis of these problems and use cases (which was already a bit
attempted from time to time in the doc) would have been more useful but
does still not have an archivable value that justifies publication as RFC
in the IETF stream (indicating IETF consensus).

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 11 Apr 2017 19:34:18 +0100

Thanks Mirja,
I think it is best that you discuss this topic with the rest of the IESG and then we can be told what to do.

(FWIW, I heard this conversation about 6 times in the 6 years I was on the IESG and the opinion swung back and forth. The IESG I was on never managed to get a clear position set down to guide the authors of future documents. Perhaps you could write one?)

Cheers,
Adrian

> -----Original Message-----
> From: Mirja Kühlewind [mailto:[email-masked]]
> Sent: 11 April 2017 19:26
> To: The IESG
> Cc: [email-masked]; Adrian Farrel; i2nsf-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Mirja Kühlewind's Discuss on draft-ietf-i2nsf-problem-and-use-cases-12:
> (with DISCUSS and COMMENT)
>

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 11 Apr 2017 14:50:35 -0400

Hi Adrian,

> On Apr 11, 2017, at 2:34 PM, Adrian Farrel <[email-masked]> wrote:
> 
> Thanks Mirja,

We did, last year: https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html <https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html>

Alissa

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 11 Apr 2017 15:54:48 -0400

Hi Adrian,

I think it's pretty clear that this should go down to informational
now.  Thanks for raising the question and having the IESG weigh in as
the published statement did not cover whether these support document
should be informational only in nature.  I do think that is the
current opinion and that they are fine to publish if the WG would like
to do so, but it's not encouraged.

We could see about updating the statement to cover your point that
support documents are to be informational.

Thank you,
Kathleen

On Tue, Apr 11, 2017 at 2:50 PM, Alissa Cooper <[email-masked]> wrote:
> (FWIW, I heard this conversation about 6 times in the 6 years I was on the
> IESG and the opinion swung back and forth. The IESG I was on never managed
> to get a clear position set down to guide the authors of future documents.
> Perhaps you could write one?)
>
>
> We did, last year:
> https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html
>
> Alissa
>
>
> Cheers,
> Adrian
>
> Subject: Mirja Kühlewind's Discuss on
> draft-ietf-i2nsf-problem-and-use-cases-12:

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 Apr 2017 17:48:26 -0400

Kathleen: 

I will submit a version -13 later tonight with the change to informational. 

Sue 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Tuesday, April 11, 2017 3:55 PM
To: Alissa Cooper
Cc: [email-masked]; Mirja Kühlewind; IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [I2nsf] Mirja Kühlewind's Discuss on draft-ietf-i2nsf-problem-and-use-cases-12: (with DISCUSS and COMMENT)

Hi Adrian,

I think it's pretty clear that this should go down to informational now.  Thanks for raising the question and having the IESG weigh in as the published statement did not cover whether these support document should be informational only in nature.  I do think that is the current opinion and that they are fine to publish if the WG would like to do so, but it's not encouraged.

We could see about updating the statement to cover your point that support documents are to be informational.

Thank you,
Kathleen

On Tue, Apr 11, 2017 at 2:50 PM, Alissa Cooper <[email-masked]> wrote:
> (FWIW, I heard this conversation about 6 times in the 6 years I was on 
> the IESG and the opinion swung back and forth. The IESG I was on never 
> managed to get a clear position set down to guide the authors of future documents.
> Cc: [email-masked]; Adrian Farrel; 
> i2nsf- [email-masked]; [email-masked]; [email-masked]
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
>
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> This document should be informational. I don't see any reason that 
> this document must be cited normatively by all following document of 
> this wg (as indicated in the shepherd write-up) and even if so that 
> does not justify publication as Standards track if the information in 
> the document is only informational.
>
>
> As soon as my discuss is resolved I will change to 'Abstain' as I 
> don't see value in the publication of this document. I can see that 
> this document was useful for discussion in the working group but I 
> don't know why it needs to be published as RFC. Also there is quite 
> some redundancy everywhere in the document aa well as between the 
> problem statement and use case part. Spelling out requirements for the 
> protocol design based on the analysis of these problems and use cases 
> (which was already a bit attempted from time to time in the doc) would 
> have been more useful but does still not have an archivable value that 
> justifies publication as RFC in the IETF stream (indicating IETF consensus).
>
>
>
>

-- 

Best regards,
Kathleen

_______________________________________________
I2nsf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Apr 2017 13:03:16 +0100

Thanks For the pointer, Alissa. I think I was aware of this IESG statement and I believe it was factored into the working group's discussions (per its charter milestone) of which documents to pursue to publication and which not.
 
But, as I believe Kathleen has just noted, this statement does not comment on the positioning on so-called support documents as Informative or Normative. This is the first point in Mirja's Discuss and the question I was asking. 
 
A lot of the issue comes down to how the RFC Editor defines a Normative reference, but maybe some of it resolves to the IESG's own definitions of downward references. Consider, if you will, the most extreme case which is a set of requirements. Such documents (often using 2119 language) do not contain protocol specifications and are not what you would normally expect to see end up as an Internet Standard. But (clearly?) you will want to reference the requirements as part of the protocol specification that follows. The question is: when stating that the protocol widget is shaped a particular way in order to satisfy a particular requirement, do you need to make normative or informative reference to that requirement, and so should the reference be Standards Track or downwards-referenced Informational.
 
(Some history that no longer applies...  Once upon a time the MoU with the ITU-T stated that they could only reference an RFC on the Standards Track. This meant that, for example, to get them to develop a protocol spec that was based on IETF requirements it was necessary to publish the requirements in a Standards Track RFC. We fixed this by re-writing the MoU and this particular shard of the problem has gone way.)
 
Why is this question important?
The working groups spend a lot of cycles trying to decide what track to put documents on. Cycles cost money and ruin lives. My approach now is to have a quick guess and punt to the IESG.
But it is apparent that the IESG is also burning cycles.
Maybe a clear directive would allow everyone to get on with their lives and spend time writing code.

[And a side comment on the IESG statement and subsequent Abstains. If the so-called support documents receive no wider review than within the WG, and if the subsequent protocol specs then attract review comments along the lines of "why are you supporting this function?" or even " there is absolutely no need for this function" then we have set ourselves up for confrontation with the WG which will feel that it has done good work based on its own view of the use cases or requirements, and the reviewer who did not comment at the right time in the process. Who knows whether this will happen and how it will be resolved?]
 
Ciao,
Adrian
 
From: Alissa Cooper [mailto:[email-masked]] 
Sent: 11 April 2017 19:51
To: [email-masked]
Cc: Mirja Kühlewind; IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-i2nsf-problem-and-use-cases-12: (with DISCUSS and COMMENT)
 
Hi Adrian,

Thanks Mirja,

We did, last year: https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html
 
Alissa

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Apr 2017 13:05:29 +0100

OK with me, Kathleen.

Can you handle as an RFC editor note?

Cheers,
Adrian

> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: 11 April 2017 20:55
> To: Alissa Cooper
> Cc: [email-masked]; [email-masked]; draft-ietf-i2nsf-problem-and-use-
> [email-masked]; Mirja Kühlewind; IESG; [email-masked]
> > to get a clear position set down to guide the authors of future documents=

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 12 Apr 2017 15:23:57 +0200

Hi Adrian,

first of all I have to say that deciding between standards track and informational did not occur to me as persistent problem. I believe there was only one other case in the last year (that was less clear than this case), and maybe one more case where the IESG decided to change from information to standards tracks. Both cases were simple to handle with not much discussion and were both less clear cases than this one. 

Regarding the IESG statement, for me it was an implicit assumption that these documents are informational anyway. I guess we could spell this out if that helps.

See more comments inline.
 
> Am 12.04.2017 um 14:03 schrieb Adrian Farrel <[email-masked]>:
> 
> A lot of the issue comes down to how the RFC Editor defines a Normative reference, but maybe some of it resolves to the IESG's own definitions of downward references. Consider, if you will, the most extreme case which is a set of requirements. Such documents (often using 2119 language) do not contain protocol specifications and are not what you would normally expect to see end up as an Internet Standard. But (clearly?) you will want to reference the requirements as part of the protocol specification that follows.

So what I really don’t understand is why you need to refer these requirements or other support documents normatively. You can alway reference them informatively and I would assume that’s fine. A normative reference means, you have to read those documents as well to be able understand the spec/implement it correctly. I don’t think any background information and motivation or reasoning falls into that category.

Further the status of a document should foremost be decided based on its content and not on the question how it could or could not be referenced in future. I know that these points are sometimes part of the discussion but usually for documents where there are also other reasons to maybe have it as standards track.

> The question is: when stating that the protocol widget is shaped a particular way in order to satisfy a particular requirement, do you need to make normative or informative reference to that requirement, and so should the reference be Standards Track or downwards-referenced Informational.

Again informative references are fine!

> (Some history that no longer applies...  Once upon a time the MoU with the ITU-T stated that they could only reference an RFC on the Standards Track. This meant that, for example, to get them to de…

Here the right solution is (which I believe was done) to explain to an informational document is an as stable reference as the standards track and can be referred without concerns, and not changing the status.

> Maybe a clear directive would allow everyone to get on with their lives and spend time writing code.

Again, I wasn’t aware of this kind of confusion. Yes, there are a lot of discussions about the right status but there is also existing documentation about what the different cases mean. For some document it’s sometimes also not that clear but usually my advise as AD is to make some choice and then wait for further feedback in the IESG evaluation and IETF last call.

However, in your case, it’s actually very clear to me that this document must be informational and as I said in my discuss I really don’t even see the point about future references because informative references are fine anyway.

> [And a side comment on the IESG statement and subsequent Abstains. If the so-called support documents receive no wider review than within the WG, and if the subsequent protocol specs then attract r…

So I think this can happen no matter if you have published any support document or not because very often these kind of document are less well reviewed in IETF last call. However, the questions you raise above are explicitly mentioned as not beginning discuss-worthy in 

so that should not hold up publication anyway.

Also it is fully okay to integrate some background information on requirements or use case in the appendix of the actual protocol spec, as mentioned in the IESG statement. If the wg feels that useful, that can be done.

Otherwise sneaking a requirements document through the process to have a handle later to undermine some discussion, seems also just not the right thing to do. I know this is phrased a little to exaggerated but my point is, while I really, really know that discussion can be very length and annoying in the IETF, usually there is a valid core that is worth having the discussion when it comes up.

Mirja

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 15 Apr 2017 11:49:22 +0100

Hello Mirja,

Thanks for continuing to discuss this issue.

> first of all I have to say that deciding between standards track and informational
> did not occur to me as persistent problem. I believe there was only one other
> case in the last year (that was less clear than this case), and maybe one more case
> where the IESG decided to change from information to standards tracks. Both
> cases were simple to handle with not much discussion and were both less clear
> cases than this one.

The IESG needs to be aware of a persistent problem: by this stage in the publication process most authors will do whatever it takes to get the document published. They are not going to dig in their heals over "editorial matters" and will simply roll over. You are, therefore, getting false data.

The situation is made "worse" by the fact that by the time a document reaches the IESG, the discussion has been had 
- with the chairs, who have good experience of what is necessary
   to get through the IESG)
- with the responsible AD (who has that experience and also their 
   own views)

> Regarding the IESG statement, for me it was an implicit assumption that these
> documents are informational anyway. I guess we could spell this out if that helps.

Surely.
I think it would be very helpful for the IESG to consider the document series again and to indicate clearly indicate how an author determines whether the document they are writing is Informational or Standards Track.

> A lot of the issue comes down to how the RFC Editor defines a Normative
> reference, but maybe some of it resolves to the IESG's own definitions of
> downward references. Consider, if you will, the most extreme case which is a set
> of requirements. Such documents (often using 2119 language) do not contain
> protocol specifications and are not what you would normally expect to see end
> up as an Internet Standard. But (clearly?) you will want to reference the
> requirements as part of the protocol specification that follows.
> 
> So what I really don’t understand is why you need to refer these requirements or
> other support documents normatively. You can alway reference them
> informatively and I would assume that’s fine. A normative reference means, you
> have to read those documents as well to be able understand the
> spec/implement it correctly. I don’t think any background information and
> motivation or reasoning falls into that category.

So let's assume we have a terminology document in our hands. Clearly (?) you can't use terms from that document without a reference to it. Is that reference normative or not? Probably it is normative because how can the reader of a protocol spec know what is being discussed if they don't know the terms?

Now more to an architecture document. This document describes the components and interfaces. It indicates what the senders and receivers of a protocol message are and what they are doing. Maybe in a very dry protocol spec you can avoid making a reference to the architecture normative, but probably not.

And what about a problem statement document that introduces terms and architecture? Isn't that document going to need to be referenced, and because the protocol specs rely on those terms and that architecture, isn't that reference normative?

[Please note that I do not personally make such claims for the document in hand, but I believe the authors and WG do make those claims.]

> Further the status of a document should foremost be decided based on its
> content and not on the question how it could or could not be referenced in
> future. I know that these points are sometimes part of the discussion but usually
> for documents where there are also other reasons to maybe have it as standards
> track.

Actually I agree. BUT that means that the work on downward references really needs to be sorted out, made clearer, and made easier.
Essentially, we could dispense with this discussion if we could stop it being any type of issue to have a normative reference to an Informational RFC.

> The question is: when stating that the protocol widget is shaped a particular
> way in order to satisfy a particular requirement, do you need to make normative
> or informative reference to that requirement, and so should the reference be
> Standards Track or downwards-referenced Informational.
> 

I should point you at https://www.ietf.org/iesg/statement/normative-informative.html
This says that 
| Normative references specify documents that must be read to understand or
| implement the technology in the new RFC, or whose technology must be 
| present for the technology in the new RFC to work.

The crunch is "understand the technology". That makes the line hard to draw.

> > The working groups spend a lot of cycles trying to decide what track to put
> > documents on. Cycles cost money and ruin lives. My approach now is to have
> > a quick guess and punt to the IESG.
> Again, I wasn’t aware of this kind of confusion. Yes, there are a lot of discussions
> about the right status but there is also existing documentation about what the
> different cases mean. For some document it’s sometimes also not that clear but
> usually my advise as AD is to make some choice and then wait for further
> feedback in the IESG evaluation and IETF last call.

OK. We are both taking the same approach :-)
But I am wondering (out loud) whether we could do better by pushing the information that feeds the final decision down the stack a little.
Why should we be "guessing" and getting the answer from our superiors? Why should we not know how to make the right decision?

> However, in your case, it’s actually very clear to me that this document must be
> informational and as I said in my discuss I really don’t even see the point about
> future references because informative references are fine anyway.

Well, I think I addressed your second part above.

As to "should *this* document be one thing or another" I suspect no-one responsible for the production actually cares. They simply want the document published. But they are also wary of a road crash later.

So what I am doing (in case it was not obvious) is gathering a paper trail that will allow the chairs to say to a future IESG, "Tough! This is what we were told to do and so the [future] document cannot be held up by this situation."

Of course, I'd be happy to not have to do this on a document-by-document basis. So some clearer direction from the IESG would always be welcome.

Thanks,
Adrian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 15 Apr 2017 14:49:23 -0500

This is not my circus, but on one point ...

On Apr 15, 2017 05:49, "Adrian Farrel" <[email-masked]> wrote:

Hello Mirja,

> cases were simple to handle with not much discussion and were both less
clear

The IESG needs to be aware of a persistent problem: by this stage in the
publication process most authors will do whatever it takes to get the
document published. They are not going to dig in their heals over
"editorial matters" and will simply roll over. You are, therefore, getting
false data.

The situation is made "worse" by the fact that by the time a document
reaches the IESG, the discussion has been had
- with the chairs, who have good experience of what is necessary
   to get through the IESG)
- with the responsible AD (who has that experience and also their
   own views)

> documents are informational anyway. I guess we could spell this out if
that helps.

Surely.
I think it would be very helpful for the IESG to consider the document
series again and to indicate clearly indicate how an author determines
whether the document they are writing is Informational or Standards Track.

> motivation or reasoning falls into that category.

So let's assume we have a terminology document in our hands. Clearly (?)
you can't use terms from that document without a reference to it. Is that
reference normative or not? Probably it is normative because how can the
reader of a protocol spec know what is being discussed if they don't know
the terms?

Now more to an architecture document. This document describes the
components and interfaces. It indicates what the senders and receivers of a
protocol message are and what they are doing. Maybe in a very dry protocol
spec you can avoid making a reference to the architecture normative, but
probably not.

And what about a problem statement document that introduces terms and
architecture? Isn't that document going to need to be referenced, and
because the protocol specs rely on those terms and that architecture, isn't
that reference normative?

[Please note that I do not personally make such claims for the document in
hand, but I believe the authors and WG do make those claims.]

> for documents where there are also other reasons to maybe have it as
standards

Actually I agree. BUT that means that the work on downward references
really needs to be sorted out, made clearer, and made easier.
Essentially, we could dispense with this discussion if we could stop it
being any type of issue to have a normative reference to an Informational
RFC.

So, here's where I'm getting stuck.

Standards-track and BCP drafts require 2/3rds of the IESG to ballot Yes or
No Objection (with no Discusses), while Informational, Experimental, and
Historic drafts require only one Yes (and no Discusses). All this, per
https://www.ietf.org/iesg/voting-procedures.html.

So my question is, if a terminology or architecture draft is going to be
foundational for Standards-track or BCP drafts, is it OK that the
foundational draft requires less review than the drafts that are building
on it?

If that's not a problem, with some plausible reasoning why not(*), I'd be
fine with allowing Normative references to Informational RFCs, with no
special attention.

(*) I'm not suggesting this is plausible reasoning, but it's worth noting
that most of the Informational documents we process are balloted by more
than half the IESG, even though one Yes is sufficient, and most go though
reviews from multiple review teams before they appear on a telechat agenda.
So maybe this is a distinction without a difference, and that is sufficient
to justify allowing Normative references to Informational RFCs.

It's also worth noting that working group charters also require only one
Yes (and no Blocks), and one might think charters are at least as
foundational as terminology or architecture drafts.

If those aren't a good enough alibis, maybe someone could come up with
another one ;-)

Spencer

> Again informative references are fine!

I should point you at https://www.ietf.org/iesg/stat
ement/normative-informative.html
This says that
| Normative references specify documents that must be read to understand or
| implement the technology in the new RFC, or whose technology must be
| present for the technology in the new RFC to work.

> > Maybe a clear directive would allow everyone to get on with their lives
and
> > spend time writing code.

OK. We are both taking the same approach :-)
But I am wondering (out loud) whether we could do better by pushing the
information that feeds the final decision down the stack a little.
Why should we be "guessing" and getting the answer from our superiors? Why
should we not know how to make the right decision?

As to "should *this* document be one thing or another" I suspect no-one
responsible for the production actually cares. They simply want the
document published. But they are also wary of a road crash later.

So what I am doing (in case it was not obvious) is gathering a paper trail
that will allow the chairs to say to a future IESG, "Tough! This is what we
were told to do and so the [future] document cannot be held up by this
situation."

Of course, I'd be happy to not have to do this on a document-by-document
basis. So some clearer direction from the IESG would always be welcome.

Thanks,
Adrian

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 18 Apr 2017 22:29:33 +0200

Hi Adrian,

again I, as AD and also as chair and contributor, didn’t notice this to be such a big problem. Yes there are over and over again discussions about what the right intented status is but often these are between standards track and experimental or BCP and informational…

Anyway to your questions below.

> Am 15.04.2017 um 12:49 schrieb Adrian Farrel <[email-masked]>:
> 

Often terminology does not need a normative reference; it’s rather a "if you are not sure, please see these documents for better definitions". So the approach that is often taken is, to list the terms and give an informational reference to the document where they are specified. I think that’s a good approach.

If that’s not good enough, you may also copy all or some of the terminology section (usually less preferred by at least this IESG) into the protocol spec itself or, of course, it still is possible to have a down-ref if that seems useful in a specific case.

> Now more to an architecture document. This document describes the components and interfaces. It indicates what the senders and receivers of a protocol message are and what they are doing. Maybe in…

Architecture documents may be different and that's one of the cases where the situation may be sometimes less clear. However, there are also protocols that can be correctly implemented without understanding all architectural consideration that lead to the final design. My general advise would be to have architecture documents as informational and potentially briefly summarize anything that may be important to know to understand the protocol spec in the protocol spec itself. However, this might be different from case to case.

> And what about a problem statement document that introduces terms and architecture? Isn't that document going to need to be referenced, and because the protocol specs rely on those terms and that a…

See above; keep the reference informational and briefly summarize if really needed.

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 19 Apr 2017 03:06:55 +0200

One more point: I’ve noticed your point that at some point people just want to get their document through the process. I’m aware of this ‚problem‘. On the one hand, I think that actually good: I’m happy if people are sure about the content and see no problem in letting the IESG figure out the actual less important questions about processing. On the other hand, I agree that we should of course try to avoid any kind of confusion people may have. However, in this case I (still) don’t understand well where this confusion is coming from and as such, at least I, don’t know how to clarify. I’m pretty sure we will further discuss this at the up-coming retreat though.

Mirja

> Am 18.04.2017 um 22:29 schrieb Mirja Kuehlewind (IETF) <[email-masked]>:
> 
> Hi Adrian,
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 18 Apr 2017 22:36:06 -0400

> One more point: I’ve noticed your point that at some point people just want to get their document through the process. I’m aware of this ‚problem‘. On the one hand, I think that actually good: I’m…

Yes, I agree that we should discuss these types of documents and our
published guidance on them to assist working groups at the retreat.
Adrian raised some important points I would bet many in the IESG
didn't read since this was just on the thread for your ballot.  It
would be more fair to WGs if we could update the guidance.  If there
will be a number of abstains on this type of document, then
informational is the only way they will get published.  Adrian raised
a number of very good points that should get considered prior to any
such update IMO.  I've always been fine with supporting what the WG
decides is best for them to accomplish their work goals, so I do
support publishing support documents.

Thank you both for the discussion.

-- 

Best regards,
Kathleen

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 19 Apr 2017 14:13:40 -0500

Hi, Kathleen,

On Tue, Apr 18, 2017 at 9:36 PM, Kathleen Moriarty <
[email-masked]> wrote:

> > One more point: I’ve noticed your point that at some point people just
> want to get their document through the process. I’m aware of this
> ‚problem‘. On the one hand, I think that actually good: I’m happy if people
> are sure about the content and see no problem in letting the IESG figure
> out the actual less important questions about processing. On the other
> hand, I agree that we should of course try to avoid any kind of confusion
> people may have. However, in this case I (still) don’t understand well
> where this confusion is coming from and as such, at least I, don’t know how
> to clarify. I’m pretty sure we will further discuss this at the up-coming
> retreat though.
>

I agree. Am I adding this to
https://trac.ietf.org/trac/iesg/wiki/RetreatInfo, or should you?

Spencer

> >> again I, as AD and also as chair and contributor, didn’t notice this to
> be such a big problem. Yes there are over and over again discussions about
> what the right intented status is but often these are between standards
> track and experimental or BCP and informational…
> >>
> >>> So let's assume we have a terminology document in our hands. Clearly
> (?) you can't use terms from that document without a reference to it. Is
> that reference normative or not? Probably it is normative because how can
> the reader of a protocol spec know what is being discussed if they don't
> know the terms?
> >>
> >> Often terminology does not need a normative reference; it’s rather a
> "if you are not sure, please see these documents for better definitions".
> So the approach that is often taken is, to list the terms and give an
> informational reference to the document where they are specified. I think
> that’s a good approach.
> >>
> >> If that’s not good enough, you may also copy all or some of the
> terminology section (usually less preferred by at least this IESG) into the
> protocol spec itself or, of course, it still is possible to have a down-ref
> if that seems useful in a specific case.
> >>
> >>>
> >> Architecture documents may be different and that's one of the cases
> where the situation may be sometimes less clear. However, there are also
> protocols that can be correctly implemented without understanding all
> architectural consideration that lead to the final design. My general
> advise would be to have architecture documents as informational and
> potentially briefly summarize anything that may be important to know to
> understand the protocol spec in the protocol spec itself. However, this
> might be different from case to case.
> >>
> >>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 19 Apr 2017 15:15:55 -0400

On Wed, Apr 19, 2017 at 3:13 PM, Spencer Dawkins at IETF
<[email-masked]> wrote:
> Hi, Kathleen,
>
> On Tue, Apr 18, 2017 at 9:36 PM, Kathleen Moriarty
> <[email-masked]> wrote:
>>
>> > want to get their document through the process. I’m aware of this ‚problem‘.
>> > On the one hand, I think that actually good: I’m happy if people are sure
>> > about the content and see no problem in letting the IESG figure out the
>> > actual less important questions about processing. On the other hand, I agree
>> > that we should of course try to avoid any kind of confusion people may have.
>> > However, in this case I (still) don’t understand well where this confusion
>> > is coming from and as such, at least I, don’t know how to clarify. I’m
>> > pretty sure we will further discuss this at the up-coming retreat though.
>>

Go for it!  Do you want to work together on this?  I think it's
important to capture Adrian's input for this discussion.

Thank you,
Kathleen

>> >> "if you are not sure, please see these documents for better definitions". So
>> >> the approach that is often taken is, to list the terms and give an
>> >> architectural consideration that lead to the final design. My general advise
>> >> would be to have architecture documents as informational and potentially
>> >> briefly summarize anything that may be important to know to understand the
>> >> protocol spec in the protocol spec itself. However, this might be different
>> >> from case to case.
>> >>
>> >>>

-- 

Best regards,
Kathleen

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 19 Apr 2017 14:17:30 -0500

FWIW,

On Tue, Apr 18, 2017 at 8:06 PM, Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> people may have.

And, on the OTHER other hand, I've certainly seen authors who said "just
tell me what it needs to say, to clear your Discuss".

Happily, I've seen less of that with recent IESGs, but it's still something
we need to watch for. If the AD knew what the document should say better
than the authors, the wrong person is the author ...

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 19 Apr 2017 14:37:05 -0500

Hi, Kathleen,

> important to capture Adrian's input for this discussion.

I added this as

   - Do we still agree with
   https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html?
   Does it say what it needs to say? (Kathleen)

I'm happy to help prepare for this, and will let you lead the discussion :-)

Spencer

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 19 Apr 2017 15:53:26 -0400

On Wed, Apr 19, 2017 at 3:37 PM, Spencer Dawkins at IETF
<[email-masked]> wrote:
> Hi, Kathleen,
>
> On Wed, Apr 19, 2017 at 2:15 PM, Kathleen Moriarty
> Do we still agree with
> https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html? Does
> it say what it needs to say? (Kathleen)
>

Thank you, Spencer!

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 26 Apr 2017 21:06:53 -0400

Kathleen: 

I apologize - but you will need to delay this drafts another 2 weeks.  My
editing capabilities only turned on today. I am working to respond to all
the emails today, but I need time to respond to Deborah's comments.   

I am still moving very slow after this illness. 

Sue Hares 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Wednesday, April 19, 2017 3:53 PM
To: Spencer Dawkins at IETF
Cc: [email-masked]; Alissa Cooper; Mirja Kuehlewind (IETF); IESG;
[email-masked]; [email-masked];
[email-masked]
Subject: Re: [I2nsf] Mirja Kühlewind's Discuss on
draft-ietf-i2nsf-problem-and-use-cases-12: (with DISCUSS and COMMENT)

On Wed, Apr 19, 2017 at 3:37 PM, Spencer Dawkins at IETF
<[email-masked]> wrote:
>> >> Yes, I agree that we should discuss these types of documents and 
>> >> our published guidance on them to assist working groups at the
retreat.
> ? Does it say what it needs to say? (Kathleen)
>

Thank you, Spencer!

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 21:32:46 -0400

Thank you, Sue for letting me know.  I hope you feel better soon!

Kathleen

-- 

Best regards,
Kathleen