Subject: Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)

From: "Songhaibin (A)" <[email-masked]>
Date: Thu, 25 Feb 2016 03:10:19 +0000

Dear Alissa and all,

I did the editing job and have submitted a new version of the document according to the comments received and the discussion in the list. I also add some text in the change history appendix for it. Please check if the updated version has addressed your comments.

https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-20

I keep the intended status of the document as it is. Alvaro thought Experimental might be a better status, when I check the change history in the document, as it is defined as a mandatory RELOAD extension, the current intended status seems suitable. Otherwise we need go through another WGLC to change the intended status.

"C.7.  Changes in version -10

   Resolve the authorization issue and other comments (e.g. define
   diagnostics as a mandatory extension) from WGLC.  And check for the
   languages.
"
Best Regards!
-Haibin

> -----Original Message-----
> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Saturday, January 30, 2016 3:13 AM
> To: Barry Leiba
> Cc: IESG; Roni Even; [email-masked];
> [email-masked]; [email-masked]; Songhaibin (A)
> Subject: Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19:
> (with DISCUSS and COMMENT)
> 
> I looked through the mailing list archives and the meeting minutes from the
> meetings around the time when the registration policy was added to the
> document (the -01). I did not see any discussion of the registration policy.
> 
> I fully agree with Haibin’s analysis, though, which is that the potential for
> introducing sensitive diagnostic types (e.g., location) is sufficient to make
> Standards Action or IETF Review a good choice. These should get IETF-wide
> security review before being added to the registries.
> 
> Alissa
> 
> > On Jan 28, 2016, at 1:47 PM, Barry Leiba <[email-masked]> wrote:
> >
> >> Does Haibin’s answer clear up your concern?
> >
> > Sorry, it must have gotten lost in the end-of-year mess.
> >
> > No, it doesn't: Haibin gives his thoughts on the question, but I asked
> > about what discussion the working group had in coming to the decision.
> > Further comment:
> >
> >>> For Sections 9.1 and 9.2, I would like to see some evidence of
> >>> discussion that resulted in the decision to make the registry
> >>> policies Standards Action.  Did the working group actually discuss
> >>> this and make a decision that Standards Action is right?  What's the
> >>> reasoning for not using some softer policy, such as "IETF Review"
> >>> (which might allow for registrations from Experimental
> >>> documents) or Specification Required (which would allow review by a
> >>> designated expert of a non-RFC specification)?  Why is Standards
> >>> Action the right thing?
> >>>
> >> The thought was that if a new value would be used for experimental
> >> purpose, then there are reserved values accordingly for overlay local
> >> use (0xF000-0xFFFE). And then if people want that value can be used
> >> across different RELOAD overlays, then they'd better need a standard
> >> track document to define it (that's why we assume it would be
> >> standard track). "Specification Required" allows non-RFC
> >> specifications, not sure that would reflect the IETF consensus
> >> (certain concerns might exist about certain kinds of diagnostic information).
> >
> > Yes, "Specification Required" allows non-RFC specifications, with a
> > designated expert to review the request and sanity-check it.  Why does
> > the working group think this registry needs only Standards Track RFCs
> > to make registrations?  Why can't IETF consensus approve a
> > non-Standards-Track RFC (as with "IETF Review")?  Why couldn't a
> > designated expert handle the review, consulting with whatever
> > appropriate working group(s) exist at the time (as with "Specification
> > Required")?
> >
> > I'm honest OK with Standards Action if that's really what the working
> > group wants, and they have a reasonable explanation for why that's
> > necessary here.  I'm asking because I can't see any evidence that it
> > was actually discussed, and I'm concerned that we consistently use
> > too-strict registration policies because we think they're necessary,
> > and that often bites us later on, when we wish we hadn't been so
> > strict.
> >
> > Can you point me at any messages or minutes that show the working
> > group discussion about the registration policy?  Can the working group
> > explain what harm could be caused if registrations were allowed to be
> > made without Standards Track RFCs?
> >
> > Barry

---

From: "Songhaibin (A)" <[email-masked]>
Date: Fri, 26 Feb 2016 01:20:56 +0000

Hi Alvaro,

Thanks. And agree with the suggested text and place for it.

Best Regards!
-Haibin

> From: Alvaro Retana (aretana) [mailto:[email-masked]]
> Sent: Friday, February 26, 2016 12:12 AM
> To: Songhaibin (A); Alissa Cooper
> Cc: Roni Even; [email-masked]; [email-masked];
> IESG; [email-masked]; Barry Leiba
> On 2/24/16, 10:10 PM, "iesg on behalf of Songhaibin (A)"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> Haibin:
> 
> 
> Hi!
> 
> >I did the editing job and have submitted a new version of the document
> >according to the comments received and the discussion in the list. I
> >also add some text in the change history appendix for it. Please check
> >if the updated version has addressed your comments.
> >
> I think that the text added in 4.3 maybe needs a little word-smithing (see below
> for a suggestion), and I think it should be in a more prominent place (I suggest
> 4.1) because the issue is not specific to Path_Track.
> Otherwise I think it's ok.
> 
> >I keep the intended status of the document as it is. Alvaro thought
> >Experimental might be a better status, when I check the change history
> >in the document, as it is defined as a mandatory RELOAD extension, the
> >current intended status seems suitable. Otherwise we need go through
> >another WGLC to change the intended status.
> 
> I don't think a new WGLC would be needed (or IETF LC for that matter) since it
> was already approved at a "higher" maturity level.  I also don't think we need
> to belabor this point much longer.
> 
> I will clear my DISCUSS.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> Suggested text update:
> 
> OLD>
>    One important thing is that, this document does not guarantee what it
>    conveys must be the information that caused the previous failures,
>    but with the retrieved information from the previous traversed nodes
>    (with high probability they are, as it cannot guarantee the exact
>    same path), a user or machine can analyze and infer what is the
>    problem.  Symmetric routing is achieved by the Via List as defined in
>    [RFC6940] (whatever DHT routing algorithms are used), but response
>    message could go through not exactly the same path as there still can
>    be node failures during that very short period.  And there can also
>    be lack of accurate path informaiton of the previously failed
>    message.
> 
> 
> NEW>
>    It is important to note that the mechanisms described in this document
>    do not guarantee that the information collected is in fact related to
>    the previous failures.  However, using the information from previous
>    traversed nodes, the user (or management system) may be able to infer
>    the problem. Symmetric routing can be achieved by using the Via List
>    [RFC6940] (or an alternate DHT routing algorithm), but the response
>    path is not guaranteed to be the same.

---

From: "Songhaibin (A)" <[email-masked]>
Date: Sat, 27 Feb 2016 01:14:30 +0000

Hi Alvaro,

I just submitted a new version, and this comment has been solved.

https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-21

Best Regards!
-Haibin

> From: P2PSIP [mailto:[email-masked]] On Behalf Of Songhaibin (A)
> Sent: Friday, February 26, 2016 9:21 AM
> To: Alvaro Retana (aretana); Alissa Cooper
> Cc: [email-masked]; [email-masked]; IESG; Barry Leiba;
> [email-masked]
> > >I did the editing job and have submitted a new version of the
> > >document according to the comments received and the discussion in the
> > >list. I also add some text in the change history appendix for it.
> > >Please check if the updated version has addressed your comments.
> > >
> > I think that the text added in 4.3 maybe needs a little word-smithing
> > (see below for a suggestion), and I think it should be in a more
> > prominent place (I suggest
> > >Experimental might be a better status, when I check the change
> > >history in the document, as it is defined as a mandatory RELOAD
> > >extension, the current intended status seems suitable. Otherwise we
> > >need go through another WGLC to change the intended status.
> >
> > I don't think a new WGLC would be needed (or IETF LC for that matter)
> > since it was already approved at a "higher" maturity level.  I also
> > don't think we need to belabor this point much longer.
> >
> > I will clear my DISCUSS.
> >
> > Thanks!
> >
> > Alvaro.
> >
> >
> > Suggested text update:
> >
> > OLD>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip