Re: Comments on draft-iab-rfc-editor: IETF control
Margaret Wasserman wrote: If an AD or the IESG makes a mistake, there is also an appeals mechanism available. There isn't any documented appeals mechanism for IAB decisions. Should there be? Depends for what. Standards related actions? Sure. Contracts and liaison decisions? No, other than those necessary for us to retain our relationship with ISOC (it takes a lawyer to answer that). Really. Let's all be adults and not micromanage people who we asked to do a job. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'A Process Experiment in Normative Reference Handling' to Experimental RFC (draft-klensin-norm-ref)
The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. If the individual submission is approved as an Experimental RFC, does that mean that the IETF will adopt the proposed experiment? If so, I don't think this draft should be approved. (Actually, I suspect the fix is in, but for the record ...) The proposal seems primarily intended to deal with the following problem. Sometimes there are cases in which a doc is ready to become a DS, but cannot, because of the infamous downref rule, which states that no DS can normatively reference a PS. The proposal leaves the downref rule in place, but allows it to be waived if the WG is willing to approve derogatory text about the referenced technology: A note is included in the reference text that indicates that the reference is to a document of a lower maturity level, that some caution should be used since it may be less stable than the document from which it is being referenced, Frankly, I think this wavier procedure is outrageous, and entirely unacceptable. The fact The fact that the referenced document has not gone through some bureaucratic process does not mean that it is any less stable, or that any more caution is required in its use. Inserting this derogatory language about technology which may be well-proven and widely deployed will be extremely misleading to the industry. I think that any rule which requires us to insert false and misleading statements in the documents should be strongly opposed. Even worse: The IESG may, at its discretion, specify the exact text to be used Great, not only is the WG required to denigrate its own technology, but the IESG is given free rein to insert whatever derogatory remarks they feel like putting in. Of course, we'll be told not to worry, since: If members of the community consider either the downward reference or the annotation text to be inappropriate, those issues can be raised at any time in the document life cycle, just as with any other text in the document. Great. Another useless thing to argue about in the WG, and another useless thing to argue about with the IESG. There are also other reasons why I find this proposed experiment disheartening. For one thing, it really misses the point. We need to simplify our processes, not make them more complicated. Either we need the downref rule or we don't. If we want to experiment, let's experiment with eliminating the rule entirely, not with fine tuning it. The real underlying problem of course is the the multi-stage standards process is just a relic from another time, and makes no sense at all in the current environment. Experiments in fine tuning the process are nothing but a distraction. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'A Process Experiment in Normative Reference Handling' to Experimental RFC (draft-klensin-norm-ref)
--On Thursday, 01 June, 2006 10:49 -0400 Eric Rosen [EMAIL PROTECTED] wrote: The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. If the individual submission is approved as an Experimental RFC, does that mean that the IETF will adopt the proposed experiment? If so, I don't think this draft should be approved. (Actually, I suspect the fix is in, but for the record ...) Actually, Eric, I don't have any idea what you are talking about. IETF doesn't adopt protocol experiments, regardless of how they are approved (some unfortunate language about process experiments, which are really quite different, notwithstanding). Of course, since individual submissions (as distinct from independent ones) are processed, and in that sense approved, by the IESG, the IESG can presumably pay as much or at little attention to them as they think the community finds appropriate. But that still has little or nothing to do with this draft. This draft is addressed primarily --almost exclusively-- to publication of documents describing standards-track protocols, not experimental or informational pieces. The proposal seems primarily intended to deal with the following problem. Sometimes there are cases in which a doc is ready to become a DS, but cannot, because of the infamous downref rule, which states that no DS can normatively reference a PS. That is correct. The proposal leaves the downref rule in place, but allows it to be waived if the WG is willing to approve derogatory text about the referenced technology: A note is included in the reference text that indicates that the reference is to a document of a lower maturity level, that some caution should be used since it may be less stable than the document from which it is being referenced, Until and unless the definitions of maturity levels are changed, that text is not derogatory, but a simply statement of fact. It carefully says may be less stable, which is true. Now, if it said ...caution should be used because the referenced document is incomplete and a piece of c**p, _that_ would be derogatory. But no such implication is present. Frankly, I think this wavier procedure is outrageous, and entirely unacceptable. The fact The fact that the referenced document has not gone through some bureaucratic process does not mean that it is any less stable, or that any more caution is required in its use. Inserting this derogatory language about technology which may be well-proven and widely deployed will be extremely misleading to the industry. If a WG agrees with you about a particular piece of technology, they have three choices: (i) Do nothing, in which case their would-be Draft Standard will sit in queue until that well-proven and widely -deployed technology is, itself, advanced to Draft Standard (or to not try to advance their Proposed Standard to Draft Standard at all). (ii) Pick up the obviously well-documented definition of the well-proven and widely deployed technology and advance it to Draft Standard. (iii) Invoke the RFC 3967 procedure for downrefs, which is more burdensome in terms of processing than the new proposal, but does not involve disclaimers. You can think of the RFC 3967 procedure as requiring a community determination that the referenced technology is stable enough to be referenced in a document of a given maturity level. So the proposed new rule adds one option to the three that are there already. It is up to the WG (or individual submitter) which one to use. This one is intended to be much more lightweight and quick than any of the existing options, but no one is forcing its use. And I assume that, if it is found too unpleasant or derogatory, then no one will use it and it will disappear after a year. Personally, that wouldn't bother me one bit -- you will recall that I have proposed and/or backed much more radical and extensive solutions to this type of problem -- but that is a rather different discussion. I think that any rule which requires us to insert false and misleading statements in the documents should be strongly opposed. But there is no requirement that this procedure be used at all. If I writing a document that needed to reference a specification that was as well-defined, mature, and stable as you posit, I'd first try to get that specification advanced to the right maturity level or, if there was some bar to doing so, I'd invoke the RFC 3697 procedure. Or I might try to build consensus for some serious discussion and action on draft-ietf-newtrk-promotion-00.txt, which essentially proposes fast-tracking the advancement of such specifications on the basis of their marketplace acceptance (and which is showing signs of vanishing
RE: Last Call: 'A Process Experiment in Normative Reference Handl ing' to Experimental RFC (draft-klensin-norm-ref)
John, In your choices below, choice i and ii are not quite separable. In the do nothing mode i, eventual advancement required to de-queue the would-be Draft Standard will only happen if choice ii is in effect. In other words, choice ii is effectively the same as choice i except that the duration of the do nothing phase is shorter (by an arbitrary amount). -- Eric Gray --- [SNIP] --- -- (From Eric Rosen) -- -- Frankly, I think this wavier procedure is outrageous, -- and entirely unacceptable. The fact The fact that the -- referenced document has not gone through some bureaucratic -- process does not mean that it is any less stable, or that any -- more caution is required in its use. Inserting this -- derogatory language about technology which may be well-proven -- and widely deployed will be extremely misleading to the -- industry. -- -- (your response) -- -- If a WG agrees with you about a particular piece of technology, -- they have three choices: -- -- (i) Do nothing, in which case their would-be Draft -- Standard will sit in queue until that well-proven and -- widely -deployed technology is, itself, advanced to -- Draft Standard (or to not try to advance their Proposed -- Standard to Draft Standard at all). -- -- (ii) Pick up the obviously well-documented definition of -- the well-proven and widely deployed technology and -- advance it to Draft Standard. -- -- (iii) Invoke the RFC 3967 procedure for downrefs, which -- is more burdensome in terms of processing than the new -- proposal, but does not involve disclaimers. You can -- think of the RFC 3967 procedure as requiring a community -- determination that the referenced technology is stable -- enough to be referenced in a document of a given -- maturity level. -- -- So the proposed new rule adds one option to the three that are -- there already. It is up to the WG (or individual submitter) -- which one to use. This one is intended to be much more -- lightweight and quick than any of the existing options, but no -- one is forcing its use. And I assume that, if it is found too -- unpleasant or derogatory, then no one will use it and it will -- disappear after a year. Personally, that wouldn't bother me one -- bit -- you will recall that I have proposed and/or backed much -- more radical and extensive solutions to this type of problem -- -- but that is a rather different discussion. -- -- I think that any rule which requires us to insert false -- and misleading statements in the documents should be strongly -- opposed. -- -- But there is no requirement that this procedure be used at all. -- If I writing a document that needed to reference a specification -- that was as well-defined, mature, and stable as you posit, I'd -- first try to get that specification advanced to the right -- maturity level or, if there was some bar to doing so, I'd invoke -- the RFC 3697 procedure. Or I might try to build consensus for -- some serious discussion and action on -- draft-ietf-newtrk-promotion-00.txt, which essentially proposes -- fast-tracking the advancement of such specifications on the -- basis of their marketplace acceptance (and which is showing -- signs of vanishing without a trace). -- -- Even worse: -- -- The IESG may, at its discretion, specify the exact text -- to be used -- -- Great, not only is the WG required to denigrate its own -- technology, but the IESG is given free rein to insert whatever -- derogatory remarks they feel like putting in. -- -- First, this seemed appropriate for an experiment of the type -- specified. In addition, like it or not, current procedures, as -- practiced, essentially give the IESG free rein to insert -- whatever remarks (derogatory or otherwise) they feel like -- inserting in anything. They are prevented from doing so by some -- combination of good sense and the presence of the appeals -- procedure, which is exactly what the paragraph you complain -- about below says... -- -- Of course, we'll be told not to worry, since: -- --If members of the community consider either the -- downward reference or the annotation text to be -- inappropriate, those issues can be raised at any time -- in the document life cycle, just as with any other text -- in the document. -- -- Great. Another useless thing to argue about in the WG, and -- another useless thing to argue about with the IESG. -- -- But the assertion you are making about a (e.g.) Proposed -- Standard specification being stable, mature, well-defined, -- widely-deployed, etc., is one that presumably should get some -- community review, rather than simply being accepted as the -- result of the divine rights of the author/editor. And that -- brings us back to the three existing choices above, which the WG -- presumably needs to argue about today. The WG's only choice -- without such an argument is
RE: Last Call: 'A Process Experiment in Normative Reference Handl ing' to Experimental RFC (draft-klensin-norm-ref)
Eric (Rosen), Irrespective of opinions about the nature of the current process, if one RFC is advanced significantly ahead of another one that it has a normative dependency on, it is possible that the state of the art will migrate between one advancement, and the other. In the event that this occurs, the documents will be out of synch - irregardless of the actual state of the art. It is simple to fix that - either advance both at the same time, or allow them to be out of synch based on a speculative assertion that de-synchronization will not occur. In the latter case, it is certainly reasonable to allow that de-synchronization may occur - and that appears to be the intent of the note in this draft proposed process experiment. The risk is that - if the normative reference is advanced, and this produces a de-synchronization of the documents, then the referring Draft Standard will have to be updated as well. Consequently, I - for one - see nothing either false or misleading in the proposed note. I also find that addition of such a note is substantially less onerous than alternatives we have now... -- Eric (Gray) Your mail included [paraphrased]: --- [SNIP] --- -- -- Frankly, I think this [waver] procedure is outrageous, and entirely -- unacceptable. The fact [...] that the referenced document has not -- gone through some bureaucratic process does not mean that it is any -- less stable, or that any more caution is required in its use. -- -- Inserting this [language] about technology which may be well-proven -- and widely deployed will be extremely misleading to the industry. -- -- I think that any rule which requires us to insert false and misleading -- statements in the documents should be strongly opposed. -- --- [SNIP] --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'A Process Experiment in Normative Reference Handling' to Experimental RFC (draft-klensin-norm-ref)
that text is not derogatory, but a simply statement of fact. Sorry, but however you may try to talk your way out of it, a statement like that technology may be unstable is derogatory. Until and unless the definitions of maturity levels are changed, that text is not derogatory, but a simply statement of fact. I'm afraid that the facts as to whether a technology is stable are in no way dependent on the IETF's definitions of maturity levels. If a WG agrees with you about a particular piece of technology, they have three choices: Well, 4: they can issue the doc as a PS obsoleting the old PS. If I writing a document that needed to reference a specification that was as well-defined, mature, and stable as you posit, I'd first try to get that specification advanced to the right maturity level That's an interesting fact about yourself, but personally I'd prefer to spend my time doing something useful. But the assertion you are making about a (e.g.) Proposed Standard specification being stable, mature, well-defined, widely-deployed, etc., is one that presumably should get some community review Sure. The WG should not advance a doc to DS if it really depends on something which isn't stable. The WG needs to be aware of the facts, and should not be compelled to insert statements which they know to be false. you should support this on your theory that it will create more arguments and bog things down further. No, I don't think there's any need to do anything that creates more arguments and bogs things down further. I understand that there's no consensus on how to avoid the iceberg, but that doesn't mean I want to take the time to run experiments on more complicated ways to arrange the deck chairs. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: LC on draft-mankin-pub-req-08.txt
Reading this, a few items caught my eye. The POSTEDIT requirements seem to be worded as if it is desirable to minimize the changes that the document editor makes, or even the changes the document editor can make. The general tone of don't mess with the words we have carefully honed is understandable. However, in practice many of the words have not been carefully honed. And they need to be. For example, there is a document I just reviewed to which my personal reaction is this needs massive editing. It is not technically wrong. But the language use makes it hard for the reader to understand what is intended. I would sincerely hope that if it is approved as-is by the IESG that the RFC Editor would edit the document. In general the editor has little or no way to tell which words are carefully crafted. I would hate to have a presumption that all the words a sacrosanct. I realize that the text calls out the special case of don't touch a letter of this, and even acknowledges that it is a rare case. But the wording of the earlier text is not in line with that. Specifically, POSTEDIT-4 reads The IETF Technical editor should refrain from changes to improve readability that may change technical and consensus wording. This appears to be a directive that prohibits almost all changes, since in a formal sense all the words in an WG and IETF LC approved document are consensus wording. That leads to what I consider a bad situation where we have essentially prohibited the editor from editing. On a related note, POSTEDIT-3 seems to be inadvertently worded too strongly. It prohibits changes which introduce a substantial review load but only provides incremental increase in the clarity of the specification. However, by definition any change at all, even a significant change that transforms a document from unintelligible to highly readable, is always an incremental increase in the clarity of the specification. With regard to the metrics, I think that it would be helpful to separate the notion of having metrics from the specific values. I would suggest moving the specific values to an appendix, with a notation that these values are advisory and based on IETF perception at the time of writing. I don't want to lose the numbers, but I think that they have a different status as requirements than the point that these time frames should be tracked, and should have well understood targets. Separating this also allows for negotiation of cost-benefit tradeoffs without violating requirements. As a minor matter, figure one is trying to make a useful statement, but one of the headings caused me to have to spend more time staring at the figure, rather than making things clearer. In the row labeled Actors, WGLC and IETF LC appear. Those are states, not actors. Also, the action listed (Formal Reviewing) does not, as far as I know, currently occur during those phases. The formal reviewing occurs after IETF LC ends, during IESG deliberations. Yours, Joel M. Halpern ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [TLS] Review of draft-housley-tls-authz-extns-05
Folks, in the interest of keeping it simple, I withdraw the proposed
text -- I'll just submit a follow up paper using Russ's draft as a template.
-Angelos
[EMAIL PROTECTED] wrote:
Russ,
I don't think this is good use of informative text. Other
standards bodies often mark some sections of a specification
as informative, but those sections are text that is helpful
for understanding the specification, but is not required to
implement it.
The KeyNote section is clearly part of the technical specification,
and required reading to get interoperable implementations of this
feature.
Also, my reading of RFC2026 is that the Proposed Standard status
applies to whole documents, and I found nothing there that would
support approving only some specific sections of a document as
Proposed Standard, while leaving other sections as Informational
or Experimental
Best regards,
Pasi
-Original Message-
From: ext Russ Housley [mailto:[EMAIL PROTECTED]
Sent: 23 May, 2006 19:59
To: Eronen Pasi (Nokia-NRC/Helsinki)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: [TLS] Review of draft-housley-tls-authz-extns-05
Pasi:
Steve Kent and Eric Rescorla made similar comments to your
third point:
3) The document is last called for Proposed Standard, but contains
a normative reference to Informational RFC (RFC 2704). I'd
suggest removing the KeyNote stuff from this document (if someone
really wants to do KeyNote, it can be a separate document).
I would like to propose a way forward on this point. It involves
three changes.
First, I suggest a different code point assignment:
enum {
x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
saml_assertion_url(3), keynote_assertion_list(64), (255)
} AuthzDataFormat;
Second, I propose the following text:
3.3.4. KeyNote Assertion List (Informative)
When KeyNoteAssertion List is used, the field contains an ASCII-
encoded list of signed KeyNote assertions, as described
in RFC 2704
[KEYNOTE]. The assertions are separated by two '\n' (newline)
characters. A KeyNote assertion is a structure similar
to a public
key certificate; the main difference is that instead of a binding
between a name and a public key, KeyNote assertions bind
public keys
to authorization rules that are evaluated by the peer
when the sender
later issues specific requests.
When making an authorization decision based on a list of KeyNote
assertions, proper linkage between the KeyNote assertions and the
public key certificate that is transferred in the TLS Certificate
message is needed. Receivers of a KeyNote assertion list should
initialize the ACTION_AUTHORIZER variable to be the
sender's public
key, which was used to authenticate the TLS exchange.
Third, I suggest making the [KEYNOTE] reference informational.
What do you think? Is this a reasonable compromise?
Russ
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
IETF, IAB, RFC-Editor
Previously, someone wrote: I finished reading the RFC editor document and have one major concern. Ultimately, the rfc-editor function needs to be accountable to the IETF community because we're the ones paying for it. Incorrect. As I pointed out some weeks ago, and Leslie has recently repeated, IETF has never paid for the RFC-Editor. Historically, RFC-Editor was created by (D)ARPA and paid by (D)ARPA. More recently, some large commercial firms have donated substantial funds to ISOC -- with the understanding that the RFC-Editor would be among the functions paid for from those funds. [1] In particular I believe that the IETF should be able to pass a BCP placing requirements on an rfc-editor stream. We've done this with RFC 3932 for example, and I think that was a good thing. In effect, community consensus within the IETF should trump anything else. It has NOT been the case in the past that IETF was the community in control of RFC-Editor. In fact, that would represent a major, and in many people's view highly undesirable, change. Historically, RFC-Editor has served the broader Internet community, including but not limited to the IETF. In fact, the RFC-Editor has existed since the late 1960s, yet the IETF did not even exist until the middle 1980s. Now, we need to be careful about how to use that consensus. Several RFC streams serve communities broader than the IETF. Unless we have good reason to do so, we should not step on those communities by overriding their requirements. Indeed, it would be a gross assumption of non-existent authority for the IETF to over-ride the broader Internet community. In the narrow situation of preserving the integrity of the standards process, existing procedures ensure that the standards process is not bypassed by some 3rd party. There is not a problem here, nor a reason for IETF to shut down the very important non-IETF uses of the RFC publication process. Despite the best efforts of new technologies (e.g. combining Google Scholar and institutional technical reports), there are still numerous RFCs each year that are not published by IETF and yet are important for the broader Internet community (which by definition includes, but is not limited to, the IETF). There are roughly 3 categories of such documents: - independent submissions to the RFC Editor relating to technology, research, or other (non-standards) issues. - IRTF submissions to the RFC Editor (as a reminder to newcomers, the IRTF also reports to the IAB, NOT to the IETF). - publications by IAB or ISOC All 3 of those categories are important. Generally speaking, none of those categories are within the purview of the IESG or the IETF -- and NEVER have been historically (with the narrow and important exception, both historically and now, that the IESG has a chance to object to publication of something that is trying to make an end run around the IETF standards process). My long-standing personal hope is that the IRTF would have its own document describing its own processes for submission, review, and approval of IRTF documents -- rather than treating IRTF documents as individual submissions as has been done historically. In the extremely unlikely case that the IESG would try to object to publication of some IRTF document, I would think it VERY important that the IRTF document get published -- in the interest of intellectual integrity and openness. I also have specific concerns about how this document interacts with the IAOC and IASA. 1) The document gives the IAB the authority to terminate the rfc-editor contract. Depending on when we do that, there may be significant budget impacts and it may not be consistent with ISOC's carrying out its financial responsibilities to terminate the rfc-editor contract at an arbitrary point in time. The RFC Editor has reported to the IAB since about 1992 -- this was documented (if I recall correctly) in the revised process RFCs after the Cambridge Tea Party. The RFC-Editor normally has a liaison attending IAB meetings, for example. The choice of IAB was very deliberate -- to ensure that the RFC-Editor did NOT become limited in scope to just the IETF or to IETF-related documents. It is not an accident that the ISOC BoT are the ones who have to approve or disapprove appointments to the IAB. The IAB and ISOC are connected and have worked well together over the past 10+ years. So a better way to think about this is that ISOC has been paying for the RFC-Editor for years, with IAB as ISOC's manager for that function. This is remaining the case. IAB is connected to ISOC, so there is no real danger that IAB would get out of sync with ISOC. The RFC Editor has *never* reported to the IESG or IETF, though RFC-Editor has done a good job of coordinating with IESG and ensuring that IETF's interests were properly looked after. There is no real danger that this would change. 2) The
Re: [Techspec] RFC Author Count and IPR
On Thu, May 25, 2006 at 06:42:06AM -0700, Lucy E. Lynch wrote: On Thu, 25 May 2006, Harald Alvestrand wrote: Lucy E. Lynch wrote: Let me try re-stating my question. Is there a one-to-one relationship between the listed authors on an IETF document and ownership of the given document's Intellectual Property? I can answer that one... No. Thank you! Lucy E. Lynch Academic User Services not knowing Harolds legal background or current standing w/ the ABA, (or EU equivalent) I think that Bob's recommendation on getting actual legal advice on your question puts you and the organziation represented (IETF) on much better grounding than a simple; I can answer that... no on an email list. just my (uninformed) opinion. --bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: Proposed 2008 - 2010 IETF Meeting Calendar
I'd like to second this. The adjacent IETF and IEEE 802 meeting in Vancouver in November 2005 was quite convenient and cost saving for me. As long as they are adjacent in time and on the same continent, there are savings. It is much better if they are in the same city. And, I suspect, if things could be coordinated enough that they were in the same facilities for two weeks, which certainly wouldn't always be possible, then better hotel room rates and better costs per meeting day for network connectivity, A/V equipment, etc. could be negotiated. Donald -Original Message- From: Lars Eggert [mailto:[EMAIL PROTECTED] Sent: Monday, May 22, 2006 5:15 PM To: Romascanu, Dan (Dan) Cc: [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Last Call: Proposed 2008 - 2010 IETF Meeting Calendar On May 22, 2006, at 21:42, Romascanu, Dan (Dan) wrote: FWIW - if this is the case, this policy is in the disadvantage of the participants coming from out of North America for both IEEE and IETF meetings. We shall be obliged to do two trips instead of one which doubles airfare costs and requires from us to at least one supplemental weekend on the road. Having the IEEE and IETF meetings scheduled in consecutive weeks is more convenient. Let me second this - different meetings on adjacent dates are good *if* they are geographically close and thus eliminate or reduce travel. And this in independent of which country you are based in - adjacent meetings in, say, Europe, reduce travel for North Americans, too. (I do realize that this complicates the scheduling algorithm though.) Lars -- Lars Eggert NEC Network Laboratories ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Emperor Has No Clothes: Is PANA actually useful?,
I have read both PANA protocol and PANA framework drafts. I understand the concept and it seems to me an useful protocol. In particular, EAP over IP is necessary, IMO, and my understanding is that PANA base protocol is all about EAP over IP. The framework document should be an informational one and those scenarios that are described in PANA framework document should be treated as examples only. In fact, we don't see similar documents in many other WGs and therefore it should not be a requirement for PANA protocol. I also believe that many folks in IETF like to see a protocol that support EAP over IP. Since PANA has been chartered to address this problem, folks should work within the PANA WG and resolve the issues, if there is any. AFAIK, several network security experts have reviewed the PANA documents but I have not seen any major security issue with the PANA protocol discussed either in the mailing list or at the WG level. We had some discussions with the operators and many of them think that a protocol like PANA should have been available yesterday. We know few proprietary solutions that can be replaced by an IETF work like PANA. regards, -Subir --- Sam Hartman said: Hi. Speaking as an individual, I'd like to make an explicit call for members of the IETF community not involved in the PANA working group to review draft-ietf-pana-framework. Please speak up if you have done such a review or attempted such a review and been unsuccessful. Let us know what you think PANA is intended to be useful for and whether you think it is actually useful. My strong hunch is that we've chartered work for some reason, and now that the working group is nearing the end of its charter, we still don't understand why we want this thing we've built and whether it's a good idea. People aren't screaming not so much because they are happy with results but because no one actually understands PANA. I understand that there's a strong presumption that once chartered, work is useful. I'd like to challenge this presumption enough to get people to actually read the document. If people not involved in the effort sit down, read the document and understand what it's all about, my concern is satisfied. But if enough people try to read the document, try to understand and fail, we're not done yet. We certainly cannot have consensus to publish something we've tried and failed to understand. It's not just me. I've been trying to find people outside of PANA who claim to understand the effort and what it's good for and why link-layer solutions are not better. When the first discussion of PANA hit the IESG, I asked other IESG members why PANA was a good idea and what problem it solved. Don't go there, was the advice I got from the responsible AD. At that time (a year and a half ago) there was no one on the IESG who claimed to understand PANA or to think it was a good idea. I'm fairly sure that with the possible exception of Jari (who is a technical advisor to PANA), that's still true. The security community has been trying to understand PANA. I've sent multiple security reviewers at the PANA document.s They always come back fundamentally confused about what PANA is trying to do or about whether it is a good idea. They end up focusing on some detail or another and asking for some minor part of the system to be fixed. But I don't get the impression from the reviews they understand the overall picture; explicit discussion of this also indicates that they are not confident in their understanding nor do they know whether it is a good idea. We keep running back over the same ground, still confused and still trying to muddle through to no real effect. I've tried to understand it myself. I tried to understand in the BOF. It was very clear to me leaving the original PANA BOF that something was very confused. Every year or so since I've tried to go back and figure out what I missed. Eventually though I've started wondering whether the problem wasn't me, but was an actual lack of clarity. So, folks can you please help us all out. Especially if the internet area is not your primary focus, especially if you've never heard of PANA before, take a look at the framework document and all their other documents. Do you get it? Is it a good idea? Thanks for your time. P.S. Again, this is me speaking as an individual. At this late stage, it would be entirely inappropriate for me to take actions as an AD claiming that we didn't understand a problem without a strong community consensus. ___ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org
Re: The Emperor Has No Clothes: Is PANA actually useful?
Dave Crocker wrote: I would find it particularly helpful to have a concise statement from someone who says that PANA will not work. Cannot be implemented (properly) by virtue of technical errors or documentation too confusing to understand. Or cannot be deployed and used, by virtue of administrative complexity or, again, documentation too confusing to understand. The fact that the IETF is supposed to be based on Rough consensus and running code is completely being missed here. Currently there are multiple interoperable implementation of the protocol in addition to there existing an open-source implementation as well. The fact that several years of peoples work and effort has gone into this is being ignored by claims that I find quite have a vested interest. Absent this, I will ask why it is productive to note that the emperor is pursuing an idiosynchratic sartorial style? I would also expect to hear a response to this. I would also like to ask if the people who claim to be unable to understand the scenarios where PANA can be applied have attended a PANA WG meeting or have cared to ask these questions on the ML. d/ -Raj ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
Joel, Please see my comments below... -- Eric -- -Original Message- -- From: Joel M. Halpern [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, May 24, 2006 4:11 PM -- To: ietf@ietf.org -- Subject: Re: LC on draft-mankin-pub-req-08.txt -- -- Reading this, a few items caught my eye. -- -- The POSTEDIT requirements seem to be worded as if it is desirable -- to minimize the changes that the document editor makes, or even the -- changes the document editor can make. The general tone of don't -- mess with the words we have carefully honed is understandable. -- However, in practice many of the words have not been carefully -- honed. And they need to be. For example, there is a document I -- just reviewed to which my personal reaction is this needs massive -- editing. It is not technically wrong. But the language use makes -- it hard for the reader to understand what is intended. I would -- sincerely hope that if it is approved as-is by the IESG that the RFC -- Editor would edit the document. -- I believe that people are leaning in the direction of requiring authors to do a better job before gaining approval required to put the remainder of the job on the RFC Editor's desk. As worded now, it seems as if the cases to which higher numbered requirements (in the series under discussion - i.e. - requirements Req-POSTEDIT-3, 4 and 5) have progressively (or incrementally) greater restrictions on their applicability to documents generally. I think this is as it should be and it may well be the case that future IESG approvals may include a note as to which levels of editing may be applied to a given draft document. -- -- In general the editor has little or no way to tell which words are -- carefully crafted. I would hate to have a presumption that all -- the words a sacrosanct. -- I am reasonably sure that this is not as difficult as it sounds. For one thing, if the current draft revision is -23, we can be reasonably sure that tweaking anything that is not clearly a typo or spelling error will be a case of modifying carefully crafted wording. On the other hand, modifying wording of a revision -02 (or lower) document that is laced with typos, spelling and grammatical errors from end to end (the massive editing example you gave) is unlikely to fall in the same category. I believe we can expect a technical editor to use their own judgement between these two extremes - at least in most cases. -- -- I realize that the text calls out the special case of don't touch a -- letter of this, and even acknowledges that it is a rare case. But -- the wording of the earlier text is not in line with that. -- Specifically, POSTEDIT-4 reads The IETF Technical editor should -- refrain from changes to improve readability that may change -- technical and consensus wording. This appears to be a directive -- that prohibits almost all changes, since in a formal sense all the -- words in an WG and IETF LC approved document are consensus wording. -- That leads to what I consider a bad situation where we have -- essentially prohibited the editor from editing. -- Bearing in mind that asking someone to refrain from doing something is a far cry from prohibiting it, see my comment above. -- -- On a related note, POSTEDIT-3 seems to be inadvertently worded too -- strongly. It prohibits changes which introduce a substantial -- review load but only provides incremental increase in the clarity -- of the specification. However, by definition any change at all, -- even a significant change that transforms a document from -- unintelligible to highly readable, is always an incremental -- increase in the clarity of the specification. -- Here I must confess to some sympathy. Like me, you probably cringe when you here the phrase more granular because this usage is just wrong. However, in this case, one of the established definitions of incremental is: A slight, often barely perceptible augmentation. It might be better to choose a less ambiguous word, but I believe the meaning is clear. -- -- With regard to the metrics, [...] --- [SNIP] --- I agree with your other observations and suggestions. -- -- Yours, -- Joel M. Halpern -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
* *Bearing in mind that asking someone to refrain from * doing something is a far cry from prohibiting it, see my * comment above. * Sorry, I don't get that fine distinction. Are you saying, Don't do your job most of the time? Wierdness abounds here. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
Bob, Weirdness? No part of the RFC Editor's job has ever involved deliberate modification of text that reflects a carefully crafted compromise position. In the past, when any such modification has occurred inadvertently, it would usually have been reversed during an Auth48. I believe what we're trying to do is define what the RFC Editor does already in terms that might allow us to off-load part of that task. So, NO I am not saying Don't do your job most of the time - what I am saying is that restraint should be used in this task to avoid doing more than the task requires. To make this something we can look at more objectively, let's look at a different example of the same usage. Surely, you would agree that a statement such as - People should refrain from allowing their passion for precise terminology usage to prevent essential communication from ever taking place - is a far cry from - Nit-picking is prohibited. -- Eric -- -Original Message- -- From: Bob Braden [mailto:[EMAIL PROTECTED] -- Sent: Thursday, June 01, 2006 5:17 PM -- To: [EMAIL PROTECTED]; [EMAIL PROTECTED] -- Cc: ietf@ietf.org -- Subject: RE: LC on draft-mankin-pub-req-08.txt -- -- -- -- * -- *Bearing in mind that asking someone to refrain from -- * doing something is a far cry from prohibiting it, see my -- * comment above. -- * -- -- Sorry, I don't get that fine distinction. Are you saying, Don't -- do your job most of the time? Wierdness abounds here. -- -- Bob Braden -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
* * People should refrain from allowing their passion for precise * terminology usage to prevent essential communication from * ever taking place * That statement incorporates an assumption that is not true. I vaguely recall that you can prove anything starting from a false premise. Bob Braden * - is a far cry from - * * Nit-picking is prohibited. Your choice of the emotion-packed word nit-picking reveals that you and I cannot have a sensible discussion. Is a bug in a programs a nit? Is bad English grammar a nit? Is ambiguous prose or terminology a nit? Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
Bob, To me, this is a perfectly sensible discussion, and my analogy was perfectly reasonable. Joel suggested that refraining from making changes that might result in altering phraseology that was carefully arrived at was effectively prohibiting the technical editor from doing the editing job. I say that the editing job can be done - as it is being done now - within the bounds of this constraint. I think this makes a lot of sense. The Editor makes it very clear what his/her specific requirements and standards of acceptability are and these are certainly taken into account in the process of word-smithing key phraseology - in many cases if not necessarily all (especially by the time IESG approval occurs). At the same time, the people writing a specification would not normally like to feel that the Editor must be a party to word-smithing of this same key phraseology - except from the stand-point of readability and clarity within the context of the purpose of the document. The concern I see being expressed in the draft is that we want to ensure that the current practice of reasoned prudence in making editorial changes is continued. This is a perfectly valid concern. As for emotional charge in the term nit-picking - I see none. As anyone who knows me can assure you, I am the last one in the world who will throw stones in that glass house. Since the term derives from the practice of de-lousing, I can hardly imagine it to be necessarily a bad thing. Finally, ambiguity is sometimes precisely what has been negotiated into a specification and this should be legitimate if the effect of the ambiguity is irrelevant to the purpose of the document. An instance of this is an example, provided not to instruct but to illustrate functionality in the abstract. -- Eric -- -Original Message- -- From: Bob Braden [mailto:[EMAIL PROTECTED] -- Sent: Thursday, June 01, 2006 6:43 PM -- To: [EMAIL PROTECTED]; [EMAIL PROTECTED] -- Cc: [EMAIL PROTECTED]; ietf@ietf.org -- Subject: RE: LC on draft-mankin-pub-req-08.txt -- -- -- * -- * People should refrain from allowing their passion for precise -- * terminology usage to prevent essential communication from -- * ever taking place -- * -- -- That statement incorporates an assumption that is not true. -- I vaguely -- recall that you can prove anything starting from a false premise. -- -- Bob Braden -- -- * - is a far cry from - -- * -- * Nit-picking is prohibited. -- -- Your choice of the emotion-packed word nit-picking -- reveals that you and -- I cannot have a sensible discussion. Is a bug in a -- programs a nit? Is -- bad English grammar a nit? Is ambiguous prose or terminology a nit? -- -- Bob Braden -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada
There are two (2) Internet-Draft cutoff dates for the 66th IETF Meeting in Montreal, Quebec, Canada: June 19th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, June 19th at 9:00 AM ET. As always, all initial submissions with a filename beginning with draft-ietf must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, June 12th at 9:00 AM ET. June 26th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, June 26th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, July 10th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to [EMAIL PROTECTED] The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_66.html. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Operation of Anycast Services' to BCP (draft-ietf-grow-anycast)
The IESG has received a request from the Global Routing Operations WG to consider the following document: - 'Operation of Anycast Services ' draft-ietf-grow-anycast-03.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-16. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-grow-anycast-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
