Gen-ART LC review of draft-ietf-repute-media-type-10

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-repute-media-type-10 Reviewer:

Weekly posting summary for ietf@ietf.org

Total of 140 messages in the last 7 days. script run at: Fri Aug 30 00:53:02 EDT 2013 Messages | Bytes| Who +--++--+ 6.43% |9 | 6.04% |76439 | sm+i...@elandsys.com 2.86% |4 | 7.42% |93857 | doug.mtv...@

Re: Mail lost yesterday

Hello, Thanks to Bob Hinden for the quick response. What follows is a general comment. My message was not a report about an operational problem. It was about the lack of a timely notification, and maybe an explanation if anyone deems that appropriate, about these problems to the IETF commu

Mailman service interruption yesterday

Greetings: This notification is being sent to the general community at the request of the IAOC. Yesterday the IETF experienced a 5.5-hour service outage on its Mailman list processor, beginning at approximately 1530PDT yesterday. In this failure, Mailman started dropping messages, rather than bo

Re: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

On Thu, Aug 29, 2013 at 12:31 PM, John C Klensin wrote: > > > --On Wednesday, August 28, 2013 07:21 -0700 Dave Crocker > wrote: > > >> RFC 5507 primarily raises three concerns about TXT records: > > > > RFC 5507 is irrelevant to consideration of the SPFbis draft. > > > > Really. > > > > RFC 5507

Re: Mail lost yesterday

SM, The place to report IETF operational problems is . I forwarded your email. Bob On Aug 29, 2013, at 3:50 PM, SM wrote: > Hello, > > Could whoever from the IETF "leadership" who is responsible for the matter > please comment about the mail loss incident? > > I previously commented about

Mail lost yesterday

Hello, Could whoever from the IETF "leadership" who is responsible for the matter please comment about the mail loss incident? I previously commented about the visibility of IETF services. That aspect of the IETF lacks transparency [1] and leaves it to the user to guess what is wrong at his

Re: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

--On Thursday, August 29, 2013 12:28 -0700 Dave Crocker wrote: > On 8/29/2013 9:31 AM, John C Klensin wrote: >> I may be violating my promise to myself to stay out of >> SPF-specific issues, > > > Probably not, since your note has little to do with the > realities of the SPFbis draft, which i

Re: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

On 8/29/2013 9:31 AM, John C Klensin wrote: I may be violating my promise to myself to stay out of SPF-specific issues, Probably not, since your note has little to do with the realities of the SPFbis draft, which is a chartered working group product. You might want to review its charter:

LC comments on draft-cotton-rfc4020bis-01.txt

I think the procedures proposed in this draft could be simplified a bit if we'd just focus on the actual issue, viz., that the implementation and deployment of a new specification is completely decoupled from the progress of that specification through the standards process. Once any significant de

Re: External link to article on trends in anti-surveillance design

On Thu, Aug 29, 2013 at 1:50 PM, Ted Lemon wrote: > On Aug 29, 2013, at 1:22 PM, Peter Saint-Andre wrote: > > Interesting stuff, but more on-topic for the perpass list: > > I think Deans point is precisely that it is _not_ a topic that can be > restricted to the perpass list. > > Yes and yes. E

Re: Last Call: (A Reputation Query Protocol) to Proposed Standard

On Thu, Aug 29, 2013 at 8:57 AM, SM wrote: > Hi Murray, > > At 01:14 21-08-2013, Murray S. Kucherawy wrote: > >> Ah. I realize that CRLF is standard line termination for SMTP; is it >> automatically the expected line termination for all line-oriented >> protocols? I don't know about others. >>

RE: Gen-ART LC review ofdraft-ietf-mpls-return-path-specified-lsp-ping-12

HI, I do not follow all the MPLS work, this Gen-ART review is done during the IETF LC. I would think that your point should have been discussed in the WG before sending the return path ping to publication. BTW: I took a quick look at draft-andersson-mpls-lsp-ping-upd-00 third paragraph of section

Re: External link to article on trends in anti-surveillance design

On Aug 29, 2013, at 1:22 PM, Peter Saint-Andre wrote: > Interesting stuff, but more on-topic for the perpass list: I think Deans point is precisely that it is _not_ a topic that can be restricted to the perpass list.

Re: Last Call: (Early IANA Allocation of Standards Track Code Points) to Best Current Practice

--On Thursday, August 29, 2013 12:43 -0400 Barry Leiba wrote: >> In Section 2: >> >> 'a. The code points must be from a space designated as >> "Specification Required" (where an RFC will be used as the >>stable reference), "RFC Required", "IETF Review", or >>"Standards Act

Re: External link to article on trends in anti-surveillance design

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/29/13 11:17 AM, Dean Willis wrote: > > importance of including anti-surveillance features as mandatory > aspects of our protocols. Interesting stuff, but more on-topic for the perpass list: https://www.ietf.org/mailman/listinfo/perpass Peter

External link to article on trends in anti-surveillance design

Some of you may recall me ranting several years ago about the importance of including anti-surveillance features as mandatory aspects of our protocols. I seem to recall getting (mostly) politely laughed at ... Anyhow, there's an article on the topic in Wired right now that hints at the commercial

Re: Last Call: (Early IANA Allocation of Standards Track Code Points) to Best Current Practice

Hi Barry, At 09:43 29-08-2013, Barry Leiba wrote: I tripped over the same text, and I suggest rephrasing it this way: NEW The code points must be from a space designated as "Specification Required" (in cases where an RFC will be used as the stable reference), "RFC Required", "IETF Revie

Re: Last Call: (Early IANA Allocation of Standards Track Code Points) to Best Current Practice

> In Section 2: > > 'a. The code points must be from a space designated as "Specification >Required" (where an RFC will be used as the stable reference), >"RFC Required", "IETF Review", or "Standards Action".' > > I suggest not having the comment (where) and leaving it to RFC 522

Re: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

--On Wednesday, August 28, 2013 07:21 -0700 Dave Crocker wrote: >> RFC 5507 primarily raises three concerns about TXT records: > > RFC 5507 is irrelevant to consideration of the SPFbis draft. > > Really. > > RFC 5507 concerns approaches to design. However the SPFbis > draft is not designing

RE: "Deprecate"

Do you intend the same basic meaning, i.e. please don't use this in anything new, we may remove it in the future (that's two points, not one)? -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Techn

Re: Last Call: (Early IANA Allocation of Standards Track Code Points) to Best Current Practice

At 14:52 27-08-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Early IANA Allocation of Standards Track Code Points' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final c

Re: Last Call: (A Reputation Query Protocol) to Proposed Standard

Hi Murray, At 01:14 21-08-2013, Murray S. Kucherawy wrote: Ah. I realize that CRLF is standard line termination for SMTP; is it automatically the expected line termination for all line-oriented protocols? I don't know about others. I would have to write a long answer to that question. :-) I

Re: Last Call: (A Media Type for Reputation Interchange) to Proposed Standard

Hi Murray, At 00:05 21-08-2013, Murray S. Kucherawy wrote: As alluded to above, there can be quite a bit of information needed for an application to be defined beyond the defaults assumed when a name is registered. There didn't seem to be any need to require such definition to be in an IETF do

Re: "Deprecate"

Original Message - From: "Adrian Farrel" To: "'Michelle Cotton'" ; "'Dearlove, Christopher (UK)'" ; "'t.p.'" ; "'ietf'" Sent: Thursday, August 29, 2013 4:13 PM Subject: RE: "Deprecate" > That would be great. > > Should 4020bis have a gating normative reference on 5226bis? Tricky; it

Re: Gen-ART LC review ofdraft-ietf-mpls-return-path-specified-lsp-ping-12

Roni I find it difficult to know whether to agree with you or not since there is another "gorilla" operating in this namespace, namely draft-andersson-mpls-lsp-ping-upd-00 which sort of gives the option of taking out the sub-TLV types of a TLV Type into a separate registry which can then be refere

RE: "Deprecate"

That would be great. Should 4020bis have a gating normative reference on 5226bis? Adrian > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > Michelle Cotton > Sent: 29 August 2013 15:53 > To: Dearlove, Christopher (UK); t.p.; ietf > Subject: R

Re: "Deprecate"

We are working on 5226bis right now and have a plans to discuss the term in there. --Michelle Cotton Michelle Cotton Manager, IANA Services ICANN On 8/29/13 5:22 AM, "Dearlove, Christopher (UK)" wrote: >It's definitely an ISO term, I see it used for features of C++. > >There's then discussio

Re: Last Call: (Early IANA Allocation ofStandards Track Code Points) to Best Current Practice

This I-D uses the term 'deprecated' without defining it nor is the term defined in "IANA Considerations" [RFC5226] " (It does however already appear in the IANA Registry). I am familiar with the SMI definition but that seems not quite right for this context; some of the IANA uses of this have been

RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12

Hi, This is OK . I have no concerns Roni > -Original Message- > From: Loa Andersson [mailto:l...@pi.nu] > Sent: 29 August, 2013 2:46 PM > To: Roni Even > Cc: 'Mach Chen'; draft-ietf-mpls-return-path-specified-lsp- > ping@tools.ietf.org; gen-...@ietf.org; ietf@ietf.org > Subject: Re: Ge

RE: "Deprecate"

It's definitely an ISO term, I see it used for features of C++. There's then discussion even there of what it means. It is, I think, meant to be used for "we don't think you should use this, there's something better, and this is a warning that it may get removed in a future version". In the case

RE: "Deprecate"

Tom, Not a complete answer but look in RFC 4020 (especially 3.3) and draft-cotton-rfc4020bis (currently in IETF last call). Adrian > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of t.p. > Sent: 29 August 2013 12:56 > To: ietf > Subject: "Depre

"Deprecate"

I recently saw 'deprecate' used in an IANA Considerations and turned to "IANA Considerations" [RFC5226] to see how it was defined only to find no mention of it there. I am used to the term from SMI, as quoted below, but that seems not quite right, in that a deprecated IANA entry never disappears,

Re: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12

Roni, tnx - the authors should add words in the IANA section requesting that IANA add this the pointed in the registry; they normally do anyway, but writing it down should not be a problem. As for "Vendor Private" RFC 4379 says: "Values from "Vendor Private" ranges MUST NOT be registered with

RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12

Hi, This text is OK if one wants to implement this draft. My concern was about the consistency of the IANA registration so that if someone defines a new TLV type 1 based on RFC4379, IANA will know that it must update also the registry for TLV type 21. If you see no such problem, I have no concerns

RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12

Hi Roni, How about this: " No assignments of sub-TLVs in the range of 0-16383 and 32768-49161 are made directly for TLV Type 21, sub-TLVs in these ranges are copied from the assignments made for TLV Type 1 and kept the same as that for TLV Type 1. All sub-TLVs in these ranges (includ

Re: [Gen-art] Gen-ART review of draft-ietf-geopriv-res-gw-lis-discovery-05

Peter: Thank you very much for your review. Based on this review and my own review, I am recommending the approval of this draft in today's telechat. (Note that other ADs have raised a number of other issues, some of which I agree with, but I did not want to repeat their comments.) Jari On J

RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12

Hi, I am not sure you responded to my latest email. Having the policy for TLV type 1 here is not enough in my view since I only look at RFC4379 and create a new TLV type I will not know that I have to register it also for the type 21 if it will not be mentioned As for the vendor specific see my o

RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12

Hi Roni, Thanks for your detailed review and comments! Please see my reply inline... > From: Roni Even [mailto:ron.even@gmail.com] > Sent: Wednesday, August 28, 2013 9:06 PM > To: draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > Cc: ietf@ietf.org; gen-...@ietf.org > Subjec