Re: [Fecframe] IESG Eval followup: config-signaling anf rtp-raptor

["Rajiv Asati (rajiva)" <[e-mail]>]

Hi David,

I have updated the document in accordance with the comments received so
far, and submitted the -07 version for us to make progress.
	
1. Adrian Farrel: Comment (2011-11-03)::= Updated the abstract and
Introduction section.
2. Gonzalo Camarillo: Comment (2011-11-03)::= Removed the normative
language.
3. Jari Arkko: Comment (2011-11-03) ::= Corrected the sections
referencing and updated the Introduction
4. Ron Bonica: Discuss (2011-11-02) ::= Removed the reference to that
expired draft.
5. Russ Housley: Comment (2011-11-03)::= All accepted. Updated the
relevant text.
6. Stephen Farrell: Comment (2011-11-01::= Cryptography meant
encryption. Removed it as well as GDOI, and mentioned PGP.
7. Wesley Eddy: Discuss (2011-10-26) ::= Changed to Informational.
8. Pete Resnick: Discuss (2011-11-02) ::= Changed to Informational.
9. Robert Sparks: Discuss (2011-11-02)::=1. Added a para in section 5.1
to clarify this. 2. Not a complete list.
10. Robert Sparks: Comment (2011-11-02)::= Changed to Informational.
11. Sean Turner: Discuss (2011-11-02)::= Yes. Added PGP preference.
12. Sean Turner: Comment (2011-11-02)::= Yes, meant to say encryption.
Removed cryptography and references to GDOI altogether.

Cheers,
Rajiv
 
> -----Original Message-----
> From: David Harrington [mailto:[e-mail]]
> Sent: Tuesday, February 21, 2012 8:38 AM
> To: Rajiv Asati (rajiva); Greg Shepherd; [e-mail]
> Subject: Re: [Fecframe] IESG Eval followup: config-signaling anf
rtp-raptor
> 
> Hi Rajiv,
> 
> Can you get a new revision published as Informational please?
> 
> Here is an issue you really need to address in the document:
> "To make this actionable I suggest you work out very clearly what the
> purpose of
> the document is and capture that both in the Abstract and the
> Introduction. It
> would also help if you clearly defined what *you* mean by a signaling
> protocol
> because people at different layers of the stack have very different
> understandings of the term."
> 
> There are a number of other discusses that need to be addressed.
> 
> If you get a revision to me by the end of February, I can run it
through
> the system again and hopefully get it into the RFC Editor before I
step
> down as AD in March. You really don't want to start over with a new
AD.
> 
> Thanks,
> 
> --
> David Harrington
> Director, Transport Area
> Internet Engineering Task Force (IETF)
> [e-mail]
> [phone]
> 
> 
> 
> 
> 
> On 1/20/12 12:46 PM, "Rajiv Asati (rajiva)" <[e-mail]> wrote:
> 
> >Informational is fine.
> >
> >Cheers,
> >Rajiv
> >
> >> -----Original Message-----
> >> From: Greg Shepherd [mailto:[e-mail]]
> >> Sent: Friday, November 04, 2011 10:30 AM
> >> To: Rajiv Asati (rajiva); [e-mail]
> >> Subject: Fwd: IESG Eval followup: config-signaling anf rtp-raptor
> >>
> >> *,
> >>
> >> There are a few things holding up the config-sig draft, but the one
we
> >> need to help with is:
> >>
> >> MUST this doc progress as experimental, or is there WG consensus to
> >> move it to informational?
> >>
> >> Please reply promptly to the list.
> >>
> >> Thanks!,
> >> Greg
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: David Harrington <[e-mail]>
> >> Date: Fri, Nov 4, 2011 at 7:23 AM
> >> Subject: IESG Eval followup: config-signaling anf rtp-raptor
> >> To: [e-mail]
> >> Cc: [e-mail],
> >> [e-mail]
> >>
> >>
> >> Hi,
> >>
> >> The IESG reviewed the config signaling and rtp-raptor drafts.
> >> We have work to do.
> >>
> >> config-signaling:
> >> 1) Can we publish this as Informational?
> >>        Is that a problem for any cross-SDO work?
> >>        If this is published as Informational, then compliance is no
> >> longer appropriate - you don't comply to an Informational document.
so
> >> the RFC2119 keywords should disappear.
> >>
> >> 2) Ask the WG which version of GDOI is supposed to be used? See
Sean's
> >> Comments.
> >>
> >> 3) The document needs a good rewrite, especialy the Abstract and
> >> Introduction. There are Discusses and Comments from many that the
> >> document doesn't describe its purpose. This must be clairified.
> >>
> >> 4) There are Discusses and Comments from multiple ADs that must be
> >> addressed:
> >> Ron: just remove the reference; I don't know if you want to carry
any
> >> information from that expired mboned doc into this doc.
> >> Adrian: clarify what is considered a signaling protocol in this doc
> >> Gonzalo: no RFC2119 keywords in the Introduction (so normative text
> >> must be moved)
> >> Jari: internal references (are you using xml2rfc? they have ways to
> >> keep that in sync for you)
> >>        clarify how you expect this to be used re: SDP, XML, etc.
> >> Russ: Gen-ART review
> >> Sean: "MAY encrypt"
> >>        MUST is for implementers - see RFC 3365 - unless this is
> >> Informational.
> >>        GDOI - explain how to use this. Clarify which version.
> >> Stephen: "MAY encrypt" => "SHOULD encrypt using PGP or CMS"?
> >>        GDOI - how to use to manage keys?
> >> Pete: If Informational, then you can ignore his comment; If
> >> Experimental, then describe the experiment.
> >> Robert: new versus copied requirements; point to the existing rules
> >> rather than copying them here.
> >>        The #2 comment is critical - are implementers supposed to
> >> choose from one of these protocols
> >>        (i.e., these are the only ones allowed in a compliant
> >> Experimental implementation?)
> >>
> >> rpt-raptor:
> >> 1) A registration request must be sent to [e-mail] to
> >> register the types, per section 5.1 of RFC 4288. The registration
> >> template needs to be filled in
> >>
> >> 2) There are discusses from Sean, Pete, Robert and Stephen that
must
> >> be addressed, and Comments from Russ (the Gen-ART review) that
should
> >> be addressed in a Revised ID. I think the usage of RFC2119 keywords
is
> >> acceptable, but might be improved. Please read and **consider**
Pete's
> >> comments on RFC2119 usage, and then do what you think is right.
> >>
> >> Please get these Revised IDs done asap so I can send them off to
the
> >> RFC Editor.
> >>
> >> David Harrington
> >> Director, IETF Transport Area
> >> [e-mail] (preferred for ietf)
> >> [e-mail]
> >> [phone] (cell)
> >_______________________________________________
> >Fecframe mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/fecframe
>