Re: [Gen-art] Gen-ART telechat review of draft-ietf-marf-not-spam-feedback-01.txt
(Raised in LC review, no reply but it was only a week ago.) Yes, sorry. I got the review and am acting on it, but I was just waiting to roll in all the comments for a revision. In most cases, not-spam reports will probably not be taken on their own, but will be considered along with other information, analysis of the message, etc. Did you consider using a normative SHOULD NOT ... SHOULD instead of will probably not ... will? We -- the editors and the working group -- did, and we thought it best to put this in as narrative, rather than as anything normative. The WG thinks it's a difficult line to straddle, between giving advice on how to handle this stuff and trying to tell operators what to do. Similarly, in the Security Considerations, Operators need to be careful seems very mild to me. Generating hundreds of not-spam reports seems like a very plausible gambit for a spamming botnet. (A bot receives spam from one of its own swarm, and generates a completely valid not-spam report to be sent to the victim's own provider. Repeat until done.) This would essentially nullify the value of any not-spam report, unless operators deploy heuristics to detect it. Yes, and similarly here, with the balance. In fact, operators are well aware of what they have to do for these cases, and new ones become aware quickly. Still, each operator has its own way of dealing with it. The Messaging Anti-Abuse Working Group (MAAWG) has put out their recommendations for how to use complaint feedback loops, and some of what's in there will apply. They're working on re-publishing it in the IETF stream ( http://tools.ietf.org/html/draft-jdfalk-maawg-cfblbcp-01 ), and the MARF WG is working on an Applicability Statement that cites the MAAWG document and adds other recommendations ( https://tools.ietf.org/html/draft-ietf-marf-as is an early version). We think that's the right place for more detailed, and more normative-looking advice. Probably the right thing to do is to put an informative reference into this document to those other two (or just to the MARF AS), and I will do that in the revision. Barry ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Note Well applicability to bar BOFs
Hi, Jorge, I haven't seen a response from you yet? Thanks, Lars On 2011-9-9, at 19:03, Lars Eggert wrote: Hi, Jorge, related to the ID on side meetings during the IETF week, during the gen-art review of this draft, Ben had the following question, and Spencer followed it up: Ben said: -- Section 6 suggests side meetings should be (somehow informally) covered by NOTE WELL. I think this is a very dangerous suggestion. The rest of the document suggests that a side meeting has no official standing. That seems to me to mean it's no different than a group of people who coincidentally participate in the IETF having a dinner or bar meeting on any subject at any time. Or a hallway conversation, for that matter. By the logic of this section, I can't really figure out how informal a meeting would need to be before it no longer fell under NOTE WELL. In an informal meeting, the participants should be able to follow any IPR policy they like. I can even imagine an informal meeting covered by an NDA, where the participants want to decide if they want to have further discussions of a subject under IETSF IPR rules or not. I think the best we can hope to do is suggest that side meeting organizers and participants be explicit with their expectations on IPR and confidentiality, so there is less chance for down-stream surprises. If we want something stronger than that, then we really need to create a new category of official meeting. Spencer said: For what it's worth, I have the same question as Ben - if this guidance applies to the kinds of informal meetings in restaurants and bars that the IESG is encouraging, even if they aren't publicized and aren't open to the community, is there any way for two or more IETF participants to talk to each other, that's NOT under NOTE WELL? I think it DOES make sense to say that the kinds of informal meetings the IESG is discouraging - in IETF meeting rooms, with agendas, mailing lists, presentations, attendee lists, and minutes - should include NOTE WELL notifications. But if I was sitting next to Adam Roach on a plane headed for the IETF (which has happened before) when he was editor of GIN and I was chair of MARTINI (this last part did not), and we started talking about proposed changes to the GIN draft, is that covered? Could you propose a rephrasing of the original text (see below) that would clarify the issues they have raised? Thanks, Lars On 2011-2-28, at 19:33, Jorge Contreras wrote: Gonzalo -- thanks for the document context. Here's my suggestion for Section 6: 6. Applicability of IPR Rules The IETF's rules regarding intellectual property are set out in BCP 78 and 79. Among other things, these rules provide that any Contribution to the IETF Standards Process (each as defined in the rules themselves) is licensed to the IETF Trust for the IETF's use in developing standards, and also requires disclosure of related patents and patent applications. A Contribution is any submission to the IETF intended by the Contributor for publication as all or part of an Internet-Draft or RFC and any statement made within the context of an IETF activity. Thus, the fact that a Contribution is made at one of the BOFs or other unofficial or semi-official events described in this document does not change or limit the applicability of the IETF's IPR rules. If you have a question regarding the applicability of the IETF IPR rules in any specific context or to any specific activity, you should consult your attorney or make an inquiry to the IESG. Regards, Jorge smime.p7s Description: S/MIME cryptographic signature ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART LC review: draft-ietf-lisp-ms-11
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-lisp-ms-11 Reviewer: Mary Barnes Review Date: 16 September 2011 IETF LC End Date: 29 September 2011 Summary: Ready. Nits: - If other changes are required, suggest that the following be fixed, otherwise, RFC editor will fix. - Section 4.2, 2nd paragraph, 1st sentence: also be - also - Section 4.2, 5th paragraph, 2nd sentence: can supported - can be supported - Section 4.3, next to last paragraph, last sentence: as as - as - Section 4.4, 1st paragraph after list, 2nd sentence: Map-Rqeuest - Map-Request ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07
Hi Roni, On Sep 7, 2011, at 4:37 , Roni Even wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Thanks! Please resolve these comments along with any other Last Call comments you may receive. Document: draft-kompella-l2vpn-l2vpn-07 Reviewer: Roni Even Review Date: 2011–9–7 IETF LC End Date: 2011–9–27 IESG Telechat date: Summary: This draft is not ready for publication as an informational RFC. Major issues: The IANA considerations section says: “the values already allocated are in Table 1 of Section 4. The allocation policy for new entries up to and including value 127 is Standards Action. The allocation policy for values 128 through 251 is First Come First Served. The values from 252 through 255 are for Experimental Use.” Standards Action will be changed to Expert Review. Yet this is document is intended for Informational status which contradict the standard action. This is also true for the second registry defined. Is this document really an Informational one? My only comment is that it is not Historic. Minor issues: 1. In section 1.2.2 “Since traditional Layer 2 VPNs (i.e., real Frame Relay circuits connecting sites) are indistinguishable from tunnel-based VPNs from the customer's point-of-view, migrating from one to the other raises few issues.” What are the few issues? A subtlety: few issues means not many, not deep; it's a careful way of saying, just about no issues. A few issues would require elaboration. 2. In section 4 “L2VPN TLVs can be added to extend the information carried in the NLRI, using the format shown in Figure 2”. How is the TLV carried in the NLRI, in which field, section 4.1 only talk about the structure of the TLV. I'll take the figure from 3.2.2 of RFC 4761 and show where the TLVs go. 3. Section 4.2 refers to section 4 but I am not sure where this mechanism in section 4 is. Will clarify. Nits/editorial comments: 1. Section 3.1 is called network topology but the whole text is an example of a network topology. Maybe the title should be “Example of a network toplogy”. Sure. 2. Section 5 starts with “As defined so far in the document ….” But the using IP only is already discussed in previous sections. Do you have a suggestion for rewording? Thanks, Kireeti. ATT1..txt ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Review: draft-ietf-tsvwg-sctpsocket-31.txt
At 08:31 PM 9/15/2011, Joel M. Halpern wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-tsvwg-sctpsocket-31.txt Sockets API Extensions for Stream Control Transmission Protocol (SCTP) Reviewer: Joel M. Halpern Review Date: 15-Sept-2011 IETF LC End Date: 27-Sept-2011 IESG Telechat date: 6-Oct-2011 Summary: This document is ready for publication as an Informational RFC Major issues: None Minor issues: For the shepherd's consideration: Is it sufficiently clear how the source address will be selected when sending a message, if bindx or wildcarding has been used to bind multiple source addresses? My guess is that this lack of description matches other specs in how that is handled, but I wanted to check. Here's consecutive responses from the two main authors/editors: Yes, the lack of description matches what you find in other specifications at least specs to my knowledge. I think this fuzziness in the spec is so that implementors have room to play.. which they do ;-) The only thing we can add is a statement that the source address will be * one of the bounded addresses, if the socket is bound to non-wildcard addresses * one of the addresses of the host, it the socket is bound to a wildcard address. Maybe add some text regarding IPv4/IPv6. However: * I think all of this is obvious. * The crucial point, how to select a specific source address, does not belong to an API spec. Maybe in the base protocol spec. But it was left out (I think on purpose), since we do not require the SCTP to do source address selection. It might be done by the IP layer. For example, if you use a userland implementation. What do you think Joel? James Nits/editorial comments: Editorial gs/proceeded/preceded/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Review: draft-ietf-tsvwg-sctpsocket-31.txt
Good enough. If that is how it has been handled in other cases, then I can leave it as is in this case. Thanks for following up promptly, Joel On 9/16/2011 7:07 PM, James M. Polk wrote: At 08:31 PM 9/15/2011, Joel M. Halpern wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-tsvwg-sctpsocket-31.txt Sockets API Extensions for Stream Control Transmission Protocol (SCTP) Reviewer: Joel M. Halpern Review Date: 15-Sept-2011 IETF LC End Date: 27-Sept-2011 IESG Telechat date: 6-Oct-2011 Summary: This document is ready for publication as an Informational RFC Major issues: None Minor issues: For the shepherd's consideration: Is it sufficiently clear how the source address will be selected when sending a message, if bindx or wildcarding has been used to bind multiple source addresses? My guess is that this lack of description matches other specs in how that is handled, but I wanted to check. Here's consecutive responses from the two main authors/editors: Yes, the lack of description matches what you find in other specifications at least specs to my knowledge. I think this fuzziness in the spec is so that implementors have room to play.. which they do ;-) The only thing we can add is a statement that the source address will be * one of the bounded addresses, if the socket is bound to non-wildcard addresses * one of the addresses of the host, it the socket is bound to a wildcard address. Maybe add some text regarding IPv4/IPv6. However: * I think all of this is obvious. * The crucial point, how to select a specific source address, does not belong to an API spec. Maybe in the base protocol spec. But it was left out (I think on purpose), since we do not require the SCTP to do source address selection. It might be done by the IP layer. For example, if you use a userland implementation. What do you think Joel? James Nits/editorial comments: Editorial gs/proceeded/preceded/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
