Re: [MEDIACTRL] Update of AD review of draft-ietf-mediactrl-mrb (for -14) (and now for -15)

[Lorenzo Miniero <[e-mail]>]

Dear Robert et. all,

actually I did reply to that message, the day after that. I'm pasting the reply inline here, hoping it did actually address your concerns.

To summarize, there actually still are a couple of things to fix:

   1. you're right about the IANA question, we did a search&replace for all the parts where the issue occurred (in the v13) but not for all of them, and then forgot to complete the job. We'll fix this in the new version.

   2. We also forgot to add the civicAddress thing to the Security Considerations. We added text in the elements description to specify its optional and implementation specific usage, but it still needs to be clarified in the Security section. We'll fix this in the new version as well.


Considering the Internet Draft Cut-off, do we need to actually publish the draft, or due to its current state should we proceed in a different way for it?

Thanks,
Lorenzo



-------- Original Message --------
Subject: 	Re: MRB Proposed Text
Date: 	Tue, 21 Aug 2012 12:04:11 +0200
From: 	Lorenzo Miniero <[e-mail]>
Organisation: 	Meetecho
To: 	Robert Sparks <[e-mail]>
CC: 	Eric Burger <[e-mail]>, Worley Dale 
<[e-mail]>, Boulton Chris <[e-mail]>



Hi Robert,

please see inline,


On Mon, 20 Aug 2012 11:03:08 -0500
Robert Sparks <[e-mail]> wrote:

> I _would_ like an updated writeup using the new template. Please provide
> a link to my AD review of (-12)
> in the archives in the review section of that writeup.
>
> The only thing that might be WGLC is the change to the schema in, for
> example,  5.1.4.21. (The addition
> of the keying-mechanism element). It's ok with me to make sure that gets
> reviewed in IETF LC instead of waiting for an additional WGLC.
>
> Has the updated schema been validated? (Who did the work there - it's
> worth giving them credit in the writeup).
>


I validated the schema after each change, since I also needed to update the call flows accordingly.


> The placement of the new text in 5.2.2.1 introduces a small problem. The
> sentence that follows it ("The following additional steps") could be
> read to only apply if the INVITE was offerless. I suggest breaking that
> last sentence off the paragraph into a paragraph of its own that starts
> the list.
>
> There are a few things from my original AD review that I'm not finding a
> response on list or in the document to. Apologies if we resolved them
> some other way - if so, help me find a record of that to point to. Most
> of them are things that won't hold the document up, (the IANA should get
> fixed before IETF LC though), but they all should be addressed before we
> get to the IESG.
>
> They are:
>
> > The phrase "compliant with the specification in the related IANA
> > registry (e.g., "msc-ivr/1.0"), for which the <...> applies" occurs
> > throughout the document. It is not precise. Which related IANA
> > registry? I think you are trying to say "as it appears in 'Control
> > Packages' subregistry of the 'IANA Media Control Channel Framework
> > Parameters' registry. Since this occurs so often, it might be worth
> > figuring out a way to present this using a reference.
> This was adjusted in many, but not all places it occurred in the
> document.  It still occurs in 5.2.5.1.1.2 for example. Was that on purpose?
>


Probably something that survived the search&replace hunt.


> >
> > Section 5.1.3.1 - Please clarify the scope of uniqueness of id.
> > Is it the intent that these only be unique within the scope of a given
> > MS, MRB pair? Or is there a need for it to be unique across all the
> > subscriptions concurrent in a given deployment?
> >
> > Section 5.1.3.1's description of <expires> confuses what the MRB is
> > asking for vs what the MS gave it.
> > This may be a structural problem - this section is about requests, and
> > its description of <subscription> is written from a request
> > point of view, but <subscription> is reused by responses in 5.1.5.
> > This section should be clear that this is just the duration the MRB is
> > asking for, and that the MS may provide a different value, and if it
> > does, that's what to use to determine when to "subscribe again". It's
> > also only implicit right now that if a success response doesn't say
> > anything about the duration of the subscription, the duration is what
> > was requested (or at least that's how I'm reading the document).
> > Please make that clearer. (Editorial question: Why is the discussion
> > of this request and response separated by the (really long) discussion
> > of the notification?)
> This got handled for the similar questions I asked about 5.1.4.1, but
> these two don't seem to be addressed?
>


Quoting my old mail from the 9th of July:

"I moved mrbresponse right after mrbrequest, so the indexes of the related sections changed. I don't have the doc and diff in front of me right now (they're at my lab and I'm at home right now) but I should have clarified that. I'll check if I forgot to add the text I wanted to put in there: some text was already in place to address this, so it was a minor revision anyway."

What you're looking for should be explained at the end of 5.1.3.1, where we explain the <subscription> element behaviour.


> > In section 5.1.4.14, what does it mean to "support" these kinds of
> > tone? Can you provide pointers to help explain how this will be used?
> I remember discussing this, but I'm not finding the resolution on the
> list or here.
>


I did answer about this, providing 3-4 links from the ML that showed when this was asked for/discussed in the ML, and how it was presented. Unfortunately my mail provider sucks and I lost all my sent mail, so I'll try and dig the ML again for the links. In case the mail didn't get lost, though, you should have it in some of my older replies anyway (I guess 9-10th of July, since that's when I published v13).


> And finally - I am still very nervous about the inclusion of a civic
> address with no discussion of the potential security ramifications of
> exposing that address or of using that address as part of computation
> (which the newly added text says an element may do). The security
> considerations section should at least call out that there is risk here.
>


You're right, we planned to add some text about that but I guess this slipped through when we worked on the doc. We'll add some text in the security considerations to clarify this. By the way, that old mail with links to the ML also had information on when and why this civic was introduced (which if I recall correctly is one of the other points you made at the time).

Lorenzo

> RjS
>
>
> On 8/20/12 9:11 AM, Eric Burger wrote:
> > Dale: Think we need another WGLC? I doubt it. What do you think?
> > Presuming not, do we need another shepherd writeup?
> >
> > RJS: Thoughts?
> >
> > On Aug 20, 2012, at 4:20 AM, Chris Boulton wrote:
> >
> >> http://www.ietf.org/id/draft-ietf-mediactrl-mrb-14.txt
> >>
> >> Chris.
> >>
> >>
> >> On 17/08/2012 15:01, Eric Burger wrote:
> >>> It's only 130 pages. Let's be done with it.
> >>>
> >>> On Aug 16, 2012, at 5:32 AM, Chris Boulton wrote:
> >>>
> >>>> All,
> >>>>
> >>>> Find attached version -14 which I have scrubbed and added the
> >>>> missing text.  Shall I just go ahead and submit?  Also checked with
> >>>> IDNits.
> >>>>
> >>>> Thanks.
> >>>>
> >>>> Chris.
> >>>>
> >>>>
> >>>> On 30/07/2012 11:26, Eric Burger wrote:
> >>>>> Lovely.
> >>>>>
> >>>>> On Jul 29, 2012, at 11:36 PM, Chris Boulton wrote:
> >>>>>
> >>>>>> Take two:
> >>>>>>
> >>>>>> The media resource request information, as defined by the
> >>>>>>     <mediaResourceRequest> element fromSection 11  <http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-13#section-11>, is carried in a SIP
> >>>>>>     INVITE request.  The INVITE request will be constructed as it would
> >>>>>>     have been to connect to a media server, as defined by the Media
> >>>>>>     Control Channel Framework [RFC6230  <http://tools.ietf.org/html/rfc6230>].  It should be noted that this
> >>>>>>     specification does not exclude the use of an offer-less INVITE as
> >>>>>>     defined in section [ref] of [ref].  Using offer-less INVITE messages
> >>>>>>     to an MRB can potentially cause confusion when applying resource selection
> >>>>>>     algorithms and an MRB, like any other SIP device, can choose to reject with
> >>>>>>     a 4xx response.  For an offer-less INVITE to be treated appropriately,
> >>>>>>     additional contextual information would need to be provided
> >>>>>>     with the request which is out of the scope for this document. The
> >>>>>>     following additional steps MUST be followed when using the Consumer interface:
> >>>>>> If this is OK I will move on to my final review.
> >>>>>>
> >>>>>> Thanks.
> >>>>>>
> >>>>>> Chris.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 27/07/2012 14:30, Eric Burger wrote:
> >>>>>>> Since any SIP device can choose to reject an offerless INVITE,
> >>>>>>> why not say so and remind the reader the MRB is not special.
> >>>>>>> Return a 4xx and be done with it.
> >>>>>>>
> >>>>>>> --
> >>>>>>> Sent from my mobile device. Thanks be to lemonade!
> >>>>>>> http://www.standardstrack.com/ietf/lemonade/
> >>>>>>>
> >>>>>>>
> >>>>>>> -----Original message-----
> >>>>>>>
> >>>>>>>     *From: *Chris Boulton <[e-mail]>*
> >>>>>>>     To: *[e-mail], [e-mail],
> >>>>>>>     [e-mail], Eric Burger <[e-mail]>*
> >>>>>>>     Sent: *Fri, Jul 27, 2012 11:39:34 GMT+00:00*
> >>>>>>>     Subject: *MRB Proposed Text
> >>>>>>>
> >>>>>>>     All,
> >>>>>>>
> >>>>>>>     Proposed additional text to section 5.2.2.1 as discussed on the list:
> >>>>>>>
> >>>>>>>
> >>>>>>>     The media resource request information, as defined by the
> >>>>>>>         <mediaResourceRequest> element fromSection 11  <http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-13#section-11>, is carried in a SIP
> >>>>>>>         INVITE request.  The INVITE request will be constructed as it would
> >>>>>>>         have been to connect to a media server, as defined by the Media
> >>>>>>>         Control Channel Framework [RFC6230  <http://tools.ietf.org/html/rfc6230>].  It should be noted that this
> >>>>>>>         specification does not exclude the use of an offer-less INVITE as
> >>>>>>>         defined in section [ref] of [ref].  Using offer-less INVITE messages
> >>>>>>>         to an MRB is likely to cause confusion when applying resource selection
> >>>>>>>         algorithms.  Additional contextual information would need to be provided
> >>>>>>>         with the request which is out of the scope for this document.  An MRB
> >>>>>>>         has the option to reject an offer-less INVITE if it does not feel it has
> >>>>>>>         the appropriate level of information to process the request.  The
> >>>>>>>         following additional steps MUST be followed when using the Consumer interface:
> >>>>>>>
> >>>>>>>     Comments please?
> >>>>>>>
> >>>>>>>     Once this is done I will do a final scrub and text edit.
> >>>>>>>     Hopefully aim for the middle of next week for submission.
> >>>>>>>
> >>>>>>>     Thanks.
> >>>>>>>
> >>>>>>>     Chris.
> >>>>>>>
> >>>>>>
> >>
> >> --
> >> Chris Boulton
> >> CTO & Co-founder
> >> NS-Technologies <http://www.ns-technologies.com/>
> >> m: +44.7876.476681
> >
>


On Tue, 23 Oct 2012 15:47:55 -0500
Robert Sparks <[e-mail]> wrote:

> Editors -
> 
> IETF LC finished for this document.
> 
> Looking through the history, I'm not seeing a response to _this_ 
> message, and the questions here all apply to -15 still.
> 
> I would like a revised ID addressing at least the IANA question.
> 
> RjS
> 
> On 8/20/12 11:07 AM, Robert Sparks wrote:
> > Has the updated schema been validated? (Who did the work there - it's 
> > worth giving them credit in the writeup).
> >
> > The placement of the new text in 5.2.2.1 introduces a small problem. 
> > The sentence that follows it ("The following additional steps") could 
> > be read to only apply if the INVITE was offerless. I suggest breaking 
> > that last sentence off the paragraph into a paragraph of its own that 
> > starts the list.
> >
> > These comments from my review of -12 do not appear to have been 
> > handled. Apologies if I'm missing where they were discussed:
> >
> >> The phrase "compliant with the specification in the related IANA 
> >> registry (e.g., "msc-ivr/1.0"), for which the <...> applies" occurs 
> >> throughout the document. It is not precise. Which related IANA 
> >> registry? I think you are trying to say "as it appears in 'Control 
> >> Packages' subregistry of the 'IANA Media Control Channel Framework 
> >> Parameters' registry. Since this occurs so often, it might be worth 
> >> figuring out a way to present this using a reference. 
> > This was adjusted in many, but not all places it occurred in the 
> > document.  It still occurs in 5.2.5.1.1.2 for example. Was that on 
> > purpose?
> So, this is also in
> 
> 5.2.5.1.2.3.
> 5.2.5.1.2.4.
> 5.2.5.1.3.3.
> 5.2.5.1.3.4.
> 5.2.5.1.3.5.
> 5.1.5.12.
> 5.1.5.15.
> 5.1.5.17.
> 
> >
> >>
> >> Section 5.1.3.1 - Please clarify the scope of uniqueness of id.
> >> Is it the intent that these only be unique within the scope of a 
> >> given MS, MRB pair? Or is there a need for it to be unique across all 
> >> the subscriptions concurrent in a given deployment?
> >>
> >> Section 5.1.3.1's description of <expires> confuses what the MRB is 
> >> asking for vs what the MS gave it.
> >> This may be a structural problem - this section is about requests, 
> >> and its description of <subscription> is written from a request
> >> point of view, but <subscription> is reused by responses in 5.1.5.  
> >> This section should be clear that this is just the duration the MRB 
> >> is asking for, and that the MS may provide a different value, and if 
> >> it does, that's what to use to determine when to "subscribe again". 
> >> It's also only implicit right now that if a success response doesn't 
> >> say anything about the duration of the subscription, the duration is 
> >> what was requested (or at least that's how I'm reading the document). 
> >> Please make that clearer. (Editorial question: Why is the discussion 
> >> of this request and response separated by the (really long) 
> >> discussion of the notification?) 
> > This got handled for the similar questions I asked about 5.1.4.1, but 
> > these two don't seem to be addressed?
> >
> >> In section 5.1.4.14,
> (should be 5.1.5.14)
> >> what does it mean to "support" these kinds of tone? Can you provide 
> >> pointers to help explain how this will be used? 
> > Was this discussed?
> >
> > And finally - I am still very nervous about the inclusion of a civic 
> > address with no discussion of the potential security ramifications of 
> > exposing that address or of using that address as part of computation 
> > (which the newly added text says an element may do). The security 
> > considerations section should at least call out that there is risk here.
> >
> > RjS
> >
> >
> 


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com