Re: [Sipbrandy] Benjamin Kaduk's Discuss on draft-ietf-sipbrandy-rtpsec-07: (with DISCUSS and COMMENT)

[Christer Holmberg <[e-mail]>]

Hi,

    >>>> I think we need to have a bit more clarity on exactly how/what parts of

    >>>> 4916 are updated (per Section 4.3).  Thta is, we have some text that's

    >>>> indented as if it's supposed to be logically inserted into a "revised

    >>>> 4916", but no indication of where or whether anything else is removed.

    >>>> Furthermore, that text includes section references to portions of 4916

    >>>> that are incorrect; normally an Update: would point to such text and say

    >>>> "this is removed" or "this is replaced by <x>", and the current

    >>>> formulation looks like it's constructing a virtual document that is

    >>>> internally inconsistent.

    >>>

    >>> I m willing to believe the draft needs more detail on what changes in 4916. But if you are asking that it

    >>> be in the form of patches, that is, “old text” to be removed and “new text” that replaces it, then I don’t

    >>> think that’s ever been a hard requirement. I think it’s perfectly okay to discuss the update conceptually.

    >>

    >> I personally prefer the latter in a lot of cases, but I think both approaches are okay. The patch approach would

    >> make sense if we actually rendered patched RFCs, but we don’t.

    >

    > I'm not insisting on patches, no.

    > The particular trigger for me here was the apparent construction of a

    > compound document that is internally inconsistent.  Even de-indenting some

    > of the text here might be enough to avoid that conflict (though I didn't

    > actually check), as then we would have "commentary surrounding the update"

    > that is not intended to be actually in force as part of the updated

    > document.



    I have traditionally been a strong believer in patches, but I have learned to accept that it may not always be needed, or even feasible. It really depends on what we update.



    If we update detailed procedures, with MUSTs, MUST NOTs etc, that will affect functionality and/or interoperability if understood wrong, we need to make sure that a non-patch

    update still keep the details clear.



    And, just to verify (I may have asked this already earlier in the process), it is ok for a BCP to make normative updates to a Standards Track, right?



    Regards,



    Christer